Re: [fossil-users] What you think about this functionality?
On Thu, Jan 26, 2012 at 08:36:46PM +0100, Remigiusz Modrzejewski wrote: I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. This kind of a thing can as well be scripted out, or implemented with use of an external merge program (I acutally manually set up to use vimdiff the few times I needed it). Any opinions? I find that git work style of git add/commit (the head, the index, the working directory) very annoying. I'm quite happy fossil does not work that way. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Jan 26, 2012, at 20:38 , Lluís Batlle i Rossell wrote: On Thu, Jan 26, 2012 at 08:36:46PM +0100, Remigiusz Modrzejewski wrote: I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. This kind of a thing can as well be scripted out, or implemented with use of an external merge program (I acutally manually set up to use vimdiff the few times I needed it). Any opinions? I find that git work style of git add/commit (the head, the index, the working directory) very annoying. I'm quite happy fossil does not work that way. :) But this is *not* about the index. It's about finer granularity of committing. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, Jan 26, 2012 at 08:40:44PM +0100, Remigiusz Modrzejewski wrote: On Thu, Jan 26, 2012 at 08:36:46PM +0100, Remigiusz Modrzejewski wrote: I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ I find that git work style of git add/commit (the head, the index, the working directory) very annoying. I'm quite happy fossil does not work that way. :) But this is *not* about the index. It's about finer granularity of committing. Hm I still see that related, but I may be confused. If not, what will be the 'storage' for what is to be commited and what not? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On 1/26/2012 11:40 AM, Remigiusz Modrzejewski wrote: On Jan 26, 2012, at 20:38 , Lluís Batlle i Rossell wrote: On Thu, Jan 26, 2012 at 08:36:46PM +0100, Remigiusz Modrzejewski wrote: I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. This kind of a thing can as well be scripted out, or implemented with use of an external merge program (I acutally manually set up to use vimdiff the few times I needed it). Any opinions? I find that git work style of git add/commit (the head, the index, the working directory) very annoying. I'm quite happy fossil does not work that way. :) But this is *not* about the index. It's about finer granularity of committing. Exactly. This is actually one of the things which are nice in git, IMHO. I love the ability to make a number of unrelated changes, or a bunch of related changes and then still be able to commit them independently. Or in the case of related stuff as a series of changes showing a nice progression in the implementation. How did your setup (with vimdiff) look like ? -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Jan 26, 2012, at 2:47 PM, Andreas Kupries wrote: I love the ability to make a number of unrelated changes, or a bunch of related changes and then still be able to commit them independently. Or in the case of related stuff as a series of changes showing a nice progression in the implementation. It's not just the ability to do it, sometimes it is natural. For example, I am working on new feature ABC and in the process I discover a new bug. I fix that bug, but it's totally unrelated to the new feature. I like to commit change XYZ as it's own commit and as a bug fix, not as part of the New ABC Feature commit. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: Hi, I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. This kind of a thing can as well be scripted out, or implemented with use of an external merge program (I acutally manually set up to use vimdiff the few times I needed it). Any opinions? I'm of the old-fashioned opinion that you ought to test your code before you check it in. (See, for example, the pre-checkin checklisthttp://www.fossil-scm.org/fossil/doc/trunk/www/checkin.wikifor Fossil itself. A similar checklist exists for SQLite.) And I don't know how you can compile and/or run a code file with only some of its changes. One does sometimes have multiple changes in a file and you want to break them up into multiple check-ins. That happens to me regularly when working on SQLite. In that case, I save off the a copy of the file that contains all changes (perhaps in the stashhttp://www.fossil-scm.org/fossil/help/stash), revert http://www.fossil-scm.org/fossil/help/revert the file to its unchanged state, then start reapplying the changes one by one, testing at each step and committing as necessary. Is that more work than git-add? Yes. But on the other hand, I don't think it is desirable to introduce new commands that make it easier for you to skip the testing step. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski http://nuclearsquid.com/writings/git-add/ Any opinions? I'm of the old-fashioned opinion that you ought to test your code before you check it in. Very well explained! I totally agree. I imagine that in git, users are expected to commit wrong untested code (thus, that may not match the commit log), and some minutes later, edit all the history to make up. Also not testing the rewrites, of course. The git workflow. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Jan 26, 2012, at 2:54 PM, Lluís Batlle i Rossell wrote: On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski http://nuclearsquid.com/writings/git-add/ Any opinions? I'm of the old-fashioned opinion that you ought to test your code before you check it in. Very well explained! I totally agree. I imagine that in git, users are expected to commit wrong untested code (thus, that may not match the commit log), and some minutes later, edit all the history to make up. Also not testing the rewrites, of course. The git workflow. Hm. I don't think that committing a partial file means you have not tested the code. Take for example my previously stated example, a file named math.b func add(a,b) return a * b end func sub(a,b) return a - b end -- New feature, multiplication func mul(a,b) return a * b end While editing I see that add is using multiplication! Doh! I whip up a few unit tests: test_equal(add(1,1), 2) test_equal(add(5,5), 10) Great, all passes. My math expansion, however, is not done. I still need to add the requested division method and other branches can benefit from my add fix, but the new math expansion still needs quite a bit of testing, peer reviews, etc… So, I want to make my add bug fix available as a simple commit that can be pulled. So, I commit just a section of math.b, and math_tests.b. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, Jan 26, 2012 at 2:51 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Hi, I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. I'm of the old-fashioned opinion that you ought to test your code before you check it in. The --interactive option is not really appropriate for the commit command, for the reason cited above. But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. I can also see it being useful on merge, especially when combined with --cherrypick. But not on commit; the thought of adding --interactive to commit gives me shivers. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, 26 Jan 2012 20:54:19 +0100 Lluís Batlle i Rossell vi...@viric.name wrote: On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski http://nuclearsquid.com/writings/git-add/ Any opinions? I'm of the old-fashioned opinion that you ought to test your code before you check it in. Very well explained! I totally agree. I imagine that in git, users are expected to commit wrong untested code (thus, that may not match the commit log), and some minutes later, edit all the history to make up. Also not testing the rewrites, of course. The git workflow. I commit untested code all the time, just to save the state of it. Of course, I *only* do this in my local repo, not to something anyone else might see. If I'm using a CSCM, I'll create a private branch for that purpose. Anything that gets pushed (or merged to the trunk) will be tested before the push, and if that results in a merge, tested before the merge results are committed. The Git philosophy seems to be that the repository is as important as anything else produced by the product, so editing history is crucial functionality. So they have tools to collapse/reorder/rewrite commits and hide all that. Personally, I think having accurate history is more important (one of the reasons I don't use git any more), and don't mind exposing it to those I share the code with. That said, between stashes and the ability to check a bug fix working copy out of the same repo (my usual mode for such), there's more than enough ways to deal with multitasking. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, 2012-01-26 at 15:06 -0500, Richard Hipp wrote: But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. That's a fantastic idea. I have tended to do this by saying fossil stash diff and hand editing the output before applying the patch(es). This works of course but is clumsy and time-consuming enough that more often than I am proud of I end up just skipping the whole process and writing a paragraph for the commit message explaining the unrelated changes. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On 1/26/2012 12:06 PM, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:51 PM, Richard Hipp d...@sqlite.org mailto:d...@sqlite.org wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski l...@maxnet.org.pl mailto:l...@maxnet.org.pl wrote: Hi, I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. I'm of the old-fashioned opinion that you ought to test your code before you check it in. The --interactive option is not really appropriate for the commit command, for the reason cited above. But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. I can also see it being useful on merge, especially when combined with --cherrypick. But not on commit; the thought of adding --interactive to commit gives me shivers. I am not sure that this is what Remus truly proposed. He said in the first post of the thread this could be scripted out, which I take to mean as handled by some outside tool which then drives fossil itself. (It was my understanding, for example, that this functionality in git is provided by the 'git-gui' tool. It seems, now, that git-add -patch might be the underlying functionality). With this in mind, the proposed 'stash -interactive' might be the one change to fossil needed to support what he wants, with the full workflow something along the lines of fossil stash save ; # save edits loop fossil stash --interactive ... ; # select and ... fossil commit ; # commit pieces repeat fossil stash pop ; # any remaining chunks go back to regular editing Of course, it could possibly be done with fossil stash diff as well, and a separate (gui) tool helping with selecting pieces from the patch. (Instead of editing in a regular editor.) At least some of the appeal might be how easy the git-gui tool makes it to (graphically) select the chunks, even pieces of chunks, to commit. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
It's a nice alternative to Git's model, too; something that would serve to distinguish Fossil further from Git. Bill On Thu, Jan 26, 2012 at 10:17 PM, Themba Fletcher themba.fletc...@gmail.com wrote: On Thu, 2012-01-26 at 15:06 -0500, Richard Hipp wrote: But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. That's a fantastic idea. I have tended to do this by saying fossil stash diff and hand editing the output before applying the patch(es). This works of course but is clumsy and time-consuming enough that more often than I am proud of I end up just skipping the whole process and writing a paragraph for the commit message explaining the unrelated changes. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, Jan 26, 2012 at 03:06:53PM -0500, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:51 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Hi, I've stumbled upon a description of something, that I missed once or twice in Fossil: http://nuclearsquid.com/writings/git-add/ Nothing that great: an ability to commit only part of changes to a file. I'm of the old-fashioned opinion that you ought to test your code before you check it in. The --interactive option is not really appropriate for the commit command, for the reason cited above. But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. I can also see it being useful on merge, especially when combined with --cherrypick. But not on commit; the thought of adding --interactive to commit gives me shivers. I quite agree. In fact, I consider the stash a kind of clipboard, where the changes are totally unlinked to the code tree. Committing, anywhere, means for me storing a full state of the tree, with a commit log describing peculiarities of that state, specially considering the previous states. When I've been usinc 'darcs', though, I consider I'm not writing a commit log for a state of the tree - I write a commit log for the diff, that can be quite unrelated to a state of the tree. In fact, most people I know use git as if it was darcs, describing more the diffs than the states of the tree in their logs. Although the git documentation states quite clear that each commit means a full state of the tree, and not a diff. To me, that highlight in the manual seems a bit a misguide, as the tool rebase, and some other important git tools, look clearly built upon having commit logs describing diffs, and not tree states. As for fossil, we may not have a way to commit partial changes of a file, but we have a way to commit partial changes of the tree: commit specific files. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Jan 26, 2012, at 21:06 , Richard Hipp wrote: The --interactive option is not really appropriate for the commit command, for the reason cited above. But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. I can also see it being useful on merge, especially when combined with --cherrypick. But not on commit; the thought of adding --interactive to commit gives me shivers. While I see nothing bad with partial commit (well, if partial commit is bad, why can we do it at file level?), doing it at stash does the trick and feels a bit more elegant. I'd vote for this option. Pozdrawiam, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Add LDFLAGS support to ./configure
Minor tweak to get LDFLAGS to work with ./configure. Previously you
would need to set CFLAGS to get ./configure to find sqlite in
/usr/local/lib. This now works:
LDFLAGS=-L/usr/local/lib ./configure --disable-internal-sqlite
--
James Turner
ja...@calminferno.net
Index: autosetup/cc.tcl
==
--- autosetup/cc.tcl
+++ autosetup/cc.tcl
@@ -454,11 +454,11 @@
switch -exact -- $opts(-lang) {
c++ {
lappend cmdline {*}[get-define CXX] {*}[get-define
CXXFLAGS]
}
c {
- lappend cmdline {*}[get-define CC] {*}[get-define
CFLAGS]
+ lappend cmdline {*}[get-define CC] {*}[get-define
CFLAGS] {*}[get-define LDFLAGS]
}
default {
autosetup-error cctest called with unknown language:
$opts(-lang)
}
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil completion for Zsh
Hi, I have created a simple Fossil completion file for Zsh. https://github.com/Dubhead/Fossil-completion-for-Zsh Enjoy :-) -- MIURA Masahiro echocham...@gmail.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
