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
--
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