Re: [IRC/patches] Failed octopus merge does not clean up

> Dnia wtorek 16. września 2008 02:20, Junio C Hamano napisał: >> Junio C Hamano <gitster@pobox.com> writes: >>> Thomas Rast <trast@student.ethz.ch> writes: >>> >>>> The merge says >>>> >>>> Trying simple merge with 5b3e4bb1c2d88d6967fb575729fbfc86df5eaec9 >>>> Simple merge did not work, trying automatic merge. >>>> Auto-merging foo >>>> ERROR: Merge conflict in foo >>>> fatal: merge program failed >>>> Automated merge did not work. >>>> Should not be doing an Octopus. >>>> Merge with strategy octopus failed. >>> ... >>> Read the second from the last line of what you were told by git. Run "git >>> reset --hard" after that, perhaps. > > The problem, as far as I understand it, is not that octopus merge fails. > The problem is that it fails halfway, and it leaves working are in > inconsistent state: git-status output with its "unmerged" suggests that > we are in the middle of the merge, but we are not. > >> By the way, there are three failure modes in Octopus. >> >> (0) your index (not work tree) is dirty; this is not limited to octopus >> merge but any merge will be refused; > > IIRC the idea of stashing away changes, doing merge, and then unstashing > was shot down as encouraging bad workflows, and more often than not > leading only to mess in workdir and index. > >> (1) while it merges other heads one-by-one, it gets conflicts on an >> earlier one, before it even attempts to merge all of them. Recording >> the heads that it so far attempted to merge in MERGE_HEAD is wrong >> (the result won't be an Octopus the end user wanted to carete), and >> recording all the heads the user gave in MERGE_HEAD is even more >> wrong (it hasn't even looked at the later heads yet, so there is no >> way for the index or work tree to contain anything from them). >> >> The above is hitting this case. > > IMVHO the correct solution would be to rollback changes to the state > before attempting a merge. I'd rather 'octopus' did its thing as > transaction; contrary to ordinary merges if merge fails it doesn't > mean necessary that it is in the state of resolvable conflict, state > we can stop at. Perhaps (if it is still a shell script, doing git-stash > at beginning, and either dropping or popping the stash at the end; > or just saving old index if it is built-in). > > > BTW. does it mean that "git merge a b" might be not the same as > "git merge b a"? >