Re: [PATCH 00/48] Handling more corner cases in merge-recursive.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren <newren@xxxxxxxxx> writes:

> On Thu, Aug 4, 2011 at 1:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Elijah Newren <newren@xxxxxxxxx> writes:
>>
>>> ... It
>>> would be nice to make use of the original index we had before
>>> unpacking, but that is overwritten at the end of unpack_trees.
>>
>> I somehow thought that we can give separate src and dst index
>> to the unpack_tree() machinery these days. Aren't you using it?
>
> Ah, yes, it appears to be possible.

But why do you care about the original index (i.e. the starting state of
our side) in the first place? If your algorithm depends on the original
index, wouldn't that mean you would screw up the same merge if the user
merged branches in the opposite direction?

I think the fact you have a path "two" at stage 0, combined with the two
diffs you ran for rename detection between the common ancestor and two
branches, should be enough to decide if one branch added the path or moved
it from elsewhere (in which case the common ancestor would not have that
path), or it kept the path at the original place (with or without content
change), no?


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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]