Re: [BUG/TEST] show breakage of status for copy+conflict

[Jonathan Nieder <jrnieder@gmail.com>]

Will Palmer wrote:

> I noticed during a rebase that a conflicted file was not showing up
> under the "both changed:" line, and was instead showing up as the
> original name of a rename.
> This was because the file had conflicts, and so was not in the index
> (or at least, not in stage 0, if I have my terminology correct), while
> another, very similar (both based on the same template) file had been
> added as part of the same change on my side.

Hmm, so:

   3
  /
 1 --- 2


1: file A with content A

2: file A with content A',
        B with content A

3: file A with content A''

where the changes A->A' and A->A'' conflict.

And behind the scenes:

There is only one merge-base, so merge_recursive has nothing to
contribute.  It’s all merge_trees()’s bag;

merge_trees() does unpack_trees() before anything else, which could
care less about rename detection;

Then it tries get_renames(), which figures out what happened;

Then process_renames(), which realizes there is nothing to do to fix
this up and reports CONFLICT (content);

And "Automatic merge failed", without any more advice to describe what
happened.

Caller tries "git status".

$ git ls-files --stage --abbrev
100644 aed72d7 1        A
100644 0abac9e 2        A
100644 a5f0d50 3        A
100644 aed72d7 0        B
$ git diff-index --cached HEAD --abbrev
:100644 000000 aed72d7... 0000000... U  A
:000000 100644 0000000... aed72d7... A  B
$ git diff-index -M --cached HEAD --abbrev
:100644 100644 aed72d7... aed72d7... R100       A       B

"git status -s" prints the right output.  So wt_status_collect() seems
to have collected the right information somehow.

> I don't really have the time right now to look for exactly what causes
> this bug, so I'm hoping that posting a demonstration of it will get
> someone else to fix it for me.

No ideas at the moment; sorry.

Jonathan