On Mon, Apr 04, 2011 at 09:55:41AM +0100, Ciaran wrote:
> [...]
> 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.
Thanks. If this patch were for actual consideration you would
inline the patch instead of sending an attachment as described
in Documentation/SubmittingPatches. Marking the subject line
with "[RFC PATCH]" lets us know that you're interested in
feedback. I have a few questions below.
> 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
> --
What if the user has a file called '.empty' in their repository?
What if the user Ctrl-C's out of mergetool -- does a stale
.empty file get left behind?
Does it work if we pass /dev/null instead?
Is such a strategy portable to Windows?
If /dev/null doesn't work, would it be better if the
empty file were given a different name?
Maybe something like foo.EMPTY.<num>.txt?
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html