merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir
authorElijah Newren <newren@gmail.com>
Wed, 8 Sep 2010 06:40:41 +0000 (00:40 -0600)
committerJunio C Hamano <gitster@pobox.com>
Fri, 10 Sep 2010 00:03:02 +0000 (17:03 -0700)
commit86273e5764ab7faaa84c3de1a428ed24a6cfdf1f
tree168f9e9e421bcd609fcadbeadfbf69715ac30278
parent56bfd762e5e602031eab8ce881b8ab0c50d2cfcc
merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir

In merge-recursive.c, whenever there was a rename where a file name on one
side of the rename matches a directory name on the other side of the merge,
then the very first check that

  string_list_has_string(&o->current_directory_set, ren1_dst)

would trigger forcing it into marking it as a rename/directory conflict.

However, if the path is only renamed on one side and a simple three-way
merge between the separate files resolves cleanly, then we don't need to
mark it as a rename/directory conflict.  So, we can simply move the check
for rename/directory conflicts after we've verified that there isn't a
rename/rename conflict and that a threeway content merge doesn't work.

This changes the particular error message one gets in the case where the
directory name that a file on one side of the rename matches is not also
part of the rename pair.  For example, with commits containing the files:

  COMMON    -> (HEAD,           MERGE )
  ---------    ---------------  -------
  sub/file1 -> (sub/file1,      newsub)
  <NULL>    -> (newsub/newfile, <NULL>)

then previously when one tried to merge MERGE into HEAD, one would get

  CONFLICT (rename/directory): Rename sub/file1->newsub in HEAD directory newsub added in merge
  Renaming sub/file1 to newsub~HEAD instead
  Adding newsub/newfile
  Automatic merge failed; fix conflicts and then commit the result.
After this patch, the error message will instead become:
  Removing newsub
  Adding newsub/newfile
  CONFLICT (file/directory): There is a directory with name newsub in merge. Adding newsub as newsub~HEAD
  Automatic merge failed; fix conflicts and then commit the result.

That makes more sense to me, because git can't know that there's a conflict
until after it's tried resolving paths involving newsub/newfile to see if
they are still in the way at the end (and if newsub/newfile is not in the
way at the end, there should be no conflict at all, which did not hold with
git previously).

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive.c
t/t3509-cherry-pick-merge-df.sh