Re: [BUG/TEST] show breakage of status for copy+conflict
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Aug 5, 2010, 12:55 UTC
- Message-ID
- <20100805125513.GB23334@burratino>
- In-Reply-To
- <1280960393-17256-1-git-send-email-wmpalmer@gmail.com>
Will Palmer wrote:
Show 7 quoted lines
> 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 A3: 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