[PATCH] Bug: failed octopus merge does not create MERGE_HEAD

[PATCH] Bug: failed octopus merge does not create MERGE_HEAD

[Michal Sojka]

Hi,

the following test case exhibits behavior which I think is a bug. If
merge-one-file cannot handle the merge we end up with unmerged index
entries and no MERGE_HEAD created. I suppose that MERGE_HEAD should be
created whenever a merge fails.

If someone gives me a hint how to correct this, I can try to do it.

Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>

---
 t/t7611-merge-octopus-fail.sh |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/t/t7611-merge-octopus-fail.sh b/t/t7611-merge-octopus-fail.sh
new file mode 100755
index 0000000..b7f983b
--- /dev/null
+++ b/t/t7611-merge-octopus-fail.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='git merge
+
+Testing octopus merge with one file changed and deleted on different branches.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+	test_commit initial file &&
+	test_commit changed file &&
+	git reset --hard initial -- &&
+	git rm file &&
+	git commit -m deleted &&
+	git tag deleted &&
+	git reset --hard initial -- &&
+	test_commit file2
+'
+test_expect_success 'failed octopus merge' '
+	git reset --hard changed &&
+	test_must_fail git merge deleted file2
+'
+
+test_expect_failure 'check that MERGE_HEAD exists' '
+	test -f .git/MERGE_HEAD
+'
+
+test_done
-- 
tg: (90a2bf9..) t/test-failed-octopus-merge (depends on: master)

Re: [PATCH] Bug: failed octopus merge does not create MERGE_HEAD

[Junio C Hamano]

Hmm.

When it detects conflicts, and refuses to make a merge, the octopus
backend says "should not be doing an octopus".  As far as I can tell,
MERGE_HEAD is useful only when resolving conflicts, and the octopus
strongly discourages recording anything but the simplest conflict-free
merges.  That makes me think that not writing the file out would be the
more correct thing to do.

One possibility I can think of is that we try to prevent user mistakes by
checking the existence of MERGE_HEAD (i.e. "can't do this, you are still
during a merge"), and not writing MERGE_HEAD in this case, but still
potentially leaving the index unmerged, may allow some operations that we
should prevent from being invoked to proceed.  Is that the issue you are
trying to address?  Or is there something else?  Why do you want to have
MERGE_HEAD?

Re: [PATCH] Bug: failed octopus merge does not create MERGE_HEAD

[Michal Sojka]

On Sat, 13 Mar 2010, Junio C Hamano wrote:
> Hmm.
> 
> When it detects conflicts, and refuses to make a merge, the octopus
> backend says "should not be doing an octopus".  As far as I can tell,
> MERGE_HEAD is useful only when resolving conflicts, and the octopus

There is also another use - see below.

> strongly discourages recording anything but the simplest conflict-free
> merges.

How can I know in advance that the merge will be conflict free? I have a
script which merges a bunch of (simple) topic branches which usually
merge without conflict, but from time to time some branch evolves and
conflicts.

> That makes me think that not writing the file out would be the more
> correct thing to do.

> 
> One possibility I can think of is that we try to prevent user mistakes by
> checking the existence of MERGE_HEAD (i.e. "can't do this, you are still
> during a merge"), and not writing MERGE_HEAD in this case, but still
> potentially leaving the index unmerged, may allow some operations that we
> should prevent from being invoked to proceed.  Is that the issue you are
> trying to address?  Or is there something else?  Why do you want to have
> MERGE_HEAD?

I'm using zsh and vcs_info which shows me git repo status in my prompt
(see e.g. http://www.jukie.net/~bart/blog/pimping-out-zsh-prompt).
vcs_info tests for existence of MERGE_HEAD to signalize that you are in
the middle of merge. If MERGE_HEAD is not created I do not see a big red
waning in my prompt and I expect the merge to be successful.

In my experiments I found that octopus creates MERGE_HEAD in several
situations but not in the one when a branch modifies the file and
another deletes it. Therefore I think it is a bug.

-Michal