The current message printed by "git merge-recursive" for a rename/delete
conflict is like this:
CONFLICT (rename/delete): new-path deleted in HEAD and renamed in
other-branch. Version other-branch of new-path left in tree.
To be more helpful, the message should show both paths of the rename and
s
Matt McCutchen writes:
> The current message printed by "git merge-recursive" for a rename/delete
> conflict is like this:
>
> CONFLICT (rename/delete): new-path deleted in HEAD and renamed in
> other-branch. Version other-branch of new-path left in tree.
>
> To be more helpful, the message shoul
Junio C Hamano writes:
> Matt McCutchen writes:
> ...
>> Please check that my refactoring is indeed correct! All the existing tests
>> pass
>> for me, but the existing test coverage of these conflict messages looks poor.
>
> This unfortunately is doing a bit too many things at once from that
>
On Wed, 2017-02-01 at 12:56 -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Matt McCutchen writes:
> > ...
> > > Please check that my refactoring is indeed correct! All the
> > > existing tests pass
> > > for me, but the existing test coverage of these conflict messages
> > > looks
Matt McCutchen writes:
> On Wed, 2017-02-01 at 12:56 -0800, Junio C Hamano wrote:
>
>> Let me make sure if I understood your changes correctly:
>> ...
>> So the condition to guard the call to update_file() also looks
>> correct to me.
>
> All of the above matches my understanding. Would it have
5 matches
Mail list logo