Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
- From
Junio C Hamano <junkio@cox.net>
- Date
- Dec 13, 2006, 06:33 UTC
- Message-ID
- <7vvekgl2z2.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0612130402300.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 21 quoted lines
> Unify the handling for cases C (add/add) and D (modify/modify). > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- > > On Tue, 12 Dec 2006, Junio C Hamano wrote: > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.