On 3/20/15, Richard Hipp <d...@sqlite.org> wrote: > 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.
I'm interested in exploring the idea of supporting some way to do "split commits", where two logical ideas end up in the same file in the same checkout, but to characterize that as "convinced that there is nothing that can go wrong" is disengenuous. What I've done so far is use the stash in an [diff]/[apply]/[pop] manner and hand-adjust patches. I've had good luck w/ the robustness of the final [pop] against patched code, and the "depth" of my mistake (a missed commit for a logical code change) has been relatively shallow to date. I wonder (off the top of my head): is there such a thing as a diff that has a range, either explicit or logical ? Example: $ fossil stash save -m 'thought 1' ./mfile -start 20 -end 80 $ fossil stash save -m 'thoght 2' ./mfile -start 90 $ fossil stash pop; fossil ci -m 'my cool feature "thought 2"' $ fossil stash pop; fossil ci -m 'my other feature "thought 1"' > 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 > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
