Re: Output from "git blame A..B -- path" for the bottom commit is misleading

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

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Jeff King <peff@xxxxxxxx> writes:
>
>> On Fri, May 09, 2014 at 07:04:05AM +0200, David Kastrup wrote:
>>
>>> Arguably if the user explicitly limited the range, he knows what he's
>>> looking at. Admittedly, I don't know offhand which options _will_
>>> produce boundary commit indications: there may be some without explicit
>>> range limitation, and we might also be talking about limiting through
>>> shallow repos (git blame on a shallow repo is probably a bad idea in the
>>> first place, but anyway).
>>
>> Yes, I was thinking mostly of "X..Y" types of ranges, which are probably
>> the most common. I hadn't considered shallow repositories, and you can
>> also hit the root commit as a boundary if you do not specify --root.
>>
>> I guess the question still in my mind is: what use does the identity of
>> the boundary commit have? That is, whether you know ahead of time where
>> the boundary is or not, is there ever a case where knowing its author
>> and/or commit sha1 is a useful piece of information, as opposed to
>> knowing that we hit a boundary at all?
>>
>> I could not think of one, but I may simply lack imagination.
>
> Well, the original message was triggered by the same "I could not
> think of one" from me ;-).

If it's the root commit, omitting all info may surprisingly make "who
should I yell at" hard.  I also am not sure about the implications in
connection with --reverse.

In connection with explicit -b however, I think it is nonsensical to
blank out only the commit id.

-- 
David Kastrup
--
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]