On Fri, Jan 14, 2011 at 5:00 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> Hello everyone! > > i just came across a case which _might_ be a mis-interaction between merge > and stash (or it might be mis-use/mis-understanding on my part)... > > i had (again) and accidental fork and merged them... > > stephan@ostwald:~/cvs/fossil/nosjob$ f merge c077876b0e > UPDATE test.cpp > stephan@ostwald:~/cvs/fossil/nosjob$ f status > ... > UPDATED_BY_MERGE test.cpp > MERGED_WITH c077876b0e275d67403b51d5f7df06b4a27c4a07 > > stephan@ostwald:~/cvs/fossil/nosjob$ f com -m "Merged yet another > accidental branch." > ... > Total network traffic: 391 bytes sent, 1769 bytes received > f: would fork. "update" first or use -f or --force. > stephan@ostwald:~/cvs/fossil/nosjob$ f pull > ... > Total network traffic: 402 bytes sent, 1790 bytes received > stephan@ostwald:~/cvs/fossil/nosjob$ f up latest > f: cannot update an uncommitted merge > > stephan@ostwald:~/cvs/fossil/nosjob$ f stash save -m foo > REVERTED: test.cpp > > stephan@ostwald:~/cvs/fossil/nosjob$ f update latest > f: cannot update an uncommitted merge > Yes. I've just been playing around with lots of combinations of "update", "merge", and "stash" and I see that it is possible to get yourself twisted around the axle, so to speak. For some real fun, mix in some branches that involve file renames! But, I find that I am usually able to dig my way out of the hole using "fossil revert". I'll try to improve the situation moving forward. But to be honest, right now I'm having a hard time trying to figure out what it should be doing in a lot of these scenarios. For example if you "stash" an uncommitted merge, then you update to some other (possibly only distantly related) branch, then apply the stash and commit, does that new commit show the original merge? What if the merge was from the branch that you applied the stash to? You'd then have a branch merging with itself? What does that mean, really? I previously disallowed updates with uncommitted merges just to avoid these kinds of contraditions.... Here's a thought: Perhaps instead of disallowing all updates if there is an uncommitted merge, perhaps only disallow updates to other branches. So if you do a merge, you can still update to descendents (thus pulling in changes that others have committed ahead of you). Such a feature would have kept you out of trouble in the first place, in the scenario above.... > > > i expected the last 'update' command to have a clean state, free of > changes. Is it correct that the merge hangs around after the stash? If so, > can you suggest a recovery strategy from this situation? i've tried: > > stephan@ostwald:~/cvs/fossil/nosjob$ f undo > UNDO test.cpp > stephan@ostwald:~/cvs/fossil/nosjob$ f update latest > f: cannot update an uncommitted merge > stephan@ostwald:~/cvs/fossil/nosjob$ f com -m "Merged yet another > accidental branch." > Autosync: http://step...@fossil.wanderinghorse.net/repos/nosjob/index.cgi > ... > Total network traffic: 390 bytes sent, 1769 bytes received > f: would fork. "update" first or use -f or --force. > > > i also tried applying the stash, but that didn't help: > > > stephan@ostwald:~/cvs/fossil/nosjob$ f stash list > 1: [ab7338a17b2ee7] on 2011-01-14 09:49:11 > foo > stephan@ostwald:~/cvs/fossil/nosjob$ f stash apply 1 > MERGE test.cpp > stephan@ostwald:~/cvs/fossil/nosjob$ f update latest > f: cannot update an uncommitted merge > stephan@ostwald:~/cvs/fossil/nosjob$ f com -m "Merged yet another > accidental branch." > ... > f: would fork. "update" first or use -f or --force. > > > and now i seem to be stuck. > > :-? > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- 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
