Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base

Johannes Schindelin [off-list ref] writes:

Unify the handling for cases C (add/add) and D (modify/modify).

Signed-off-by: Johannes Schindelin <redacted>
---

	On Tue, 12 Dec 2006, Junio C Hamano wrote:

	> Johannes Schindelin [off-list ref] writes:
	> 
	> > How about this: if there is an add/add conflict, we treat it 
	> > as if there _was_ an empty file, and we let the shiny new 
	> > xdl_merge() find the _true_ conflicts, _instead of_ removing 
	> > the file from the index, adding both files with different 
	> > "~blabla" markers appended to their file names to the working 
	> > directory.
	> 
	> I was not thinking about this t6024 test failure problem but was
	> wondering about doing exactly that in merge-recursive to match
	> the "two file merge" magic we have in git-merge-one-file.sh

	As can be seen with the test case, the result is more pleasing.

This fixes the behaviour in "both branches add the path
differently" case.  Previously merge-recursive did not create
the working tree file, but now it does just like merge-resolve.

Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.