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 Imho, the "missing piece" would be "stash" having means to do partial stashing (finer than on file-by-file base). This the would allow to do these "splittings of a mixed up check-outs" a bit easier (including testing "before" committing, no need for "partial commit" then), wouldn't it? Regards Marcel
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
