From: Junio C Hamano Date: Wed, 13 Dec 2006 06:33:21 GMT Subject: Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base Message-ID: <7vvekgl2z2.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Johannes Schindelin writes: > Unify the handling for cases C (add/add) and D (modify/modify). > > Signed-off-by: Johannes Schindelin > --- > > On Tue, 12 Dec 2006, Junio C Hamano wrote: > > > Johannes Schindelin 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.