On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf <graf.m.ml+sbf...@gmail.com> wrote:
> On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp <d...@sqlite.org> wrote: > >> On 3/20/15, Martin S. Weber <ephae...@gmx.net> wrote: >> ... > > > 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: >> ... > > (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. > > > This (2) might be easier with something like a > "partial/selective/interactive stash" as mentioned by the OP in the bottom > part of his email. > So (2a) would look like: selectively stash the "second" set of changes, > test (thus including the "first" set of changes), commit, stash pop/apply > "second", test, commit > I suppose this would make sense if there are fewer changes to "undo" in the edited code than to "re do" in the reverted code. You can achieve the same result with "fossil snapshot" (which skips the automatic revert), then "fossil gdiff" to selectively "undo" changes. Then edit/build/test/commit what remains. After that, "fossil stash gdiff" to selectively re-apply more changes. Repeat as needed
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
