Re: [Feature Request] git blame showing only revisions from git rev-list --first-parent

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

 



On Sun, Sep 13, 2015 at 3:07 AM, Jeff King <peff@xxxxxxxx> wrote:
>> The thing is, traversing first-parent chain in reverse fundamentally
>> is undefined.  You can fork multiple topics at the tip of 'master'
>> and each of the topics may be single strand of pearls, but which one
>> of the topics is the first-child-chain---there is no answer to that
>> question.
>
> In general I think I agree, but in the case of blame, we know that we
> are starting from a single tip (and we know because we are using
> first-parent that we remain in a single strand of pearls, because we
> follow only one parent and there are no cycles).

The thing is that the patch is inside revision.c machinery for --children,
and "rev-list --first-parent --children ^A ^B C" (i.e. range with multiple
bottoms) may be a perfectly a reasonable request. The requestor does
not necessarily know if A or B is an ancestor of C on the first-parent
chain. I am not sure if we are introducing unintended consequences
on this unrelated request only to change the behaviour of "blame".

For that matter, I am not sure how "blame A..B" with first-parent &
reverse should behave when A is not an ancestor on the first-parent
chain. Wouldn't we try to find a cut-point on the first-parent chain by
traversing first-parent chain from B and painting them as positive,
while traversing _all_ parents from B and painting them as negative,
until the traversal intersect? And wouldn't we discover at least two
children (one positive and one negative) for the cut point we discover
by that traversal? That cut point would be the (fake) latest state the
blame traversal starts at, and then we try to use the first (fake) parent
that in real life is the first child (which we do not have a good definition
for). And at that point a simple panda brain explodes ;-)

We might end up doing the right thing even in that case, but I haven't
convinced myself about that (yet).  If the change were limited to "blame",
the change may be much less problematic.
--
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]