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
