On 3/20/15, Martin S. Weber <ephae...@gmx.net> wrote: > On 2015-03-20 09:02:32, Richard Hipp wrote: >> (...) >> I'm still having trouble understanding how the partial commit would be >> *useful*, though. > > > Also, ideally you're working in a flow anyways (the deep meditative > state where stuff gets done (tm)); doing housekeeping (stashing here > and there; grouping related changes to single commits so that you can > cleanly test them / undo them as a human without the need for tools such > as unit-testing combined with fossil bisect) is a safe way to kill any > meditative effort (except for real housekeeping, obviously meditative > in itself). So you end up with intermingled changes which one would > like to split cleanly. >
The way I deal with this in SQLite is: (1) Make logically separate changes in separate check-outs so that they are easy to test and commit separately. A real-life example of this can be seen at https://www.sqlite.org/src/timeline?c=08958f57 - I was working on the stat4-function branch when I noticed that an unrelated comment needed to be cleaned up, so I checked in the comment fix separately, then continued merrily working away on stat4-function. (2) On the occasions when I mess up and accidentally put unrelated changes into the same check-out, I have been known to stash the whole thing, then reapply one set of changes, test, commit, then reapply the other set of changes, test, and commit again. (3) You might also check-in the whole thing into a side branch, then do multiple partial merges back into the branch you were working on, with appropriate comments on each merge. (To do the partial merge, you merge the whole change, then back out the parts that you don't want for the current partial merge, test and commit, then repeat. Copy/Paste from "fossil diff --tk" gets this done rather efficiently, in my experience.) You can argument that (2) might have been easier with a partial commit. Maybe so; maybe a little easier, but not a huge amount easier. And I would have had to skip the testing step, which might have caused problems in the future such that the total effort (effort to commit plus effort to fix problems caused by the untested commit) is greater than the effort of applying procedure (2) as written. So one can argue that partial commit might save you (a little) effort today, but will end up requiring more work in the long-term. Still, there will always be people who are convinced that there is nothing that can go wrong and what to do a partial commit against expert advise. And I am not opposed to providing some reasonable support for that in Fossil. But there needs to be a balance. We shouldn't waste too much time implementing that capability when there are other more useful features that could be added instead, and the mechanism should not get in the way of people who don't want to use it or even know about it, and it shouldn't be so easy as to encourage people to use it to their harm. -- 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
