Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Unify the handling for cases C (add/add) and D (modify/modify). > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- > > On Tue, 12 Dec 2006, Junio C Hamano wrote: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - 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