CiaranHi All,
Hopefully a quick question. Given the following scenario
mkdir git_repo cd git_repo git init echo foo > foo.txt git add foo.txt git commit -m "Initial commit" git checkout -b other echo bar > bar.txt git add bar.txt git commit -m "other commit" git checkout master echo barbarella > bar.txt git add bar.txt git commit -m "master commit" git merge other
We would expect a 'both added' merge conflict (both the other branch, and the master branch added the file named bar.txt, but with different content.) This is all good and right. So in a system configured to use p4merge as the mergetool, one fires up with 'git mergetool'
What happens now is p4merge starts and tells us:
Base: bar.txt.LOCAL.<num1>.txt Left: bar.txt.LOCAL.<num1>.txt Differences from base: 0 Right: bar.txt.LOCAL.<num2>.txt Differences from base: 1 Merge: bar.txt Conflicts:0
Presenting the left + right options on top of each other in the result window (which may be correct) and leaving the save button disabled (grayed out)
If at this point one closes the window without editing the presented (apparently merged) file, then nothing will be saved to disk and we will see:
bar.txt seems unchanged. Was the merge successful? [y/n]
In the console. Which Git wise is correct, that is exactly right, the p4merge tool hasn't made any actual changes to the underlying file.
This behaviour seems confusing to me (the p4merge client behaviour, *not* Git's) I believe it is because in the case where there is no logical base between two files the local one is arbritrarily chosen, and p4merge *thinks* that this is equal to the merge result and has nothing to persist.
I have attached a patch that resolves the issue for me (e.g. introduces the behaviour I expect) by passing a reference to an empty file in the case where there is no meaningful base. Unfortunately I don't understand enough to say whether this change is correct or not and would value feedback on it.
Many thanks - Cj.
From 8eb507ac86f952bf4700d94caa361b1632ab01a6 Mon Sep 17 00:00:00 2001 From: ciaranj <ciaranj@gmail.com> Date: Mon, 4 Apr 2011 09:24:18 +0100 Subject: [PATCH] Modified the p4merge client command to pass a reference to an empty file instead of the local file when no base revision available.
In the situation where a merge tries to add a file from one branch into a branch that already contains that file (by name), p4merge currently seems to have successfully automatically resolved the 'conflict' when it is opened (correctly if the files differed by just whitespace for example) but leaves the save button disabled. This means the user of the p4merge client cannot commit the resolved changes back to disk and merely exits, leaving the original (merge-conflicted) file in-tact on the disk.
If the user is not paying attention this file can get committed :(
With this change, p4merge appears to behave far more as expected, for example leaving the save button enabled allowing one to save the resolved file to disk. --- git-mergetool--lib.sh | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh index fb3f52b..3e486dc 100644 --- a/git-mergetool--lib.sh +++ b/git-mergetool--lib.sh @@ -262,7 +262,9 @@ run_merge_tool () { if $base_present; then "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED" else - "$merge_tool_path" "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED" + touch ".empty" + "$merge_tool_path" ".empty" "$LOCAL" "$REMOTE" "$MERGED" + rm ".empty" fi check_unchanged else
-- 1.7.3.4
