threads / discuss / 36611

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

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

## tl;dr

17 messages between May 8, 2014 and May 10, 2014.

replies: 16people: 5as markdown or json

Junio C Hamano· May 8, 2014, 20:52 UTC · lore

If you run

    $ git blame -L103,107 v2.0.0-rc0..v2.0.0-rc2 t/t9117-git-svn-init-clone.sh

you will see something like this:

    ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 103) 
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
    ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 105)         test...
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
    ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 107)         test...

It is correct to attribute these lines that have not changed since the bottom of the range (i.e. v2.0.0-rc0) to that commit, and it may be technically correct to show my name because I recorded the tree that contains these lines as v2.0.0-rc0 with that commit.

But I find it really misleading, as this is the true picture if we dug to the bottom of the history:

    $ git blame -L103,107 v2.0.0-rc2 t/t9117-git-svn-init-clone.sh
    f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 103) 
    7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_...
    f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 105)  test ! -d p...
    7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106)  git svn ini...
    f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 107)  test_must_f...

I do not expect Johan's name to appear in the output for the first one, because that would require us to dig deeper than the commit we were told to stop at, but I am wondering if we can do better than the existing "-b" option to reduce the confusion from the output.

The "-b" option blanks the commit object name, but still shows the name and timestamp for the bottom commit:

             (Junio C Hamano 2014-04-18 11:21:43 -0700 103) 
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
             (Junio C Hamano 2014-04-18 11:21:43 -0700 105)         test...
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
             (Junio C Hamano 2014-04-18 11:21:43 -0700 107)         test...

I am tempted to say "blame that is run without the --porcelain
option is a end-user facing Porcelain, and people should not be
reading its output in their scripts" and change the behaviour of the
"-b" option to instead show something like this instead:
    
    ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 103) 
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
    ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 105)         test...
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
    ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 107)         test...

which shows the commit object name, its bottom-ness and the timestamp, or even

             (                                         103) 
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
             (                                         105)         test...
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
             (                                         107)         test...

which does away with the misleading information altogether.

I myself is leaning towards the latter between the two, and not overriding "-b" but introducing another "cleanse the output of useless bottom information even more" option.

Opinions?

David Kastrup· May 8, 2014, 21:13 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> If you run
>
>     $ git blame -L103,107 v2.0.0-rc0..v2.0.0-rc2 t/t9117-git-svn-init-clone.sh
>
> you will see something like this:
>
>     ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>     ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>     ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 107)         test...
>
> It is correct to attribute these lines that have not changed since
> the bottom of the range (i.e. v2.0.0-rc0) to that commit,

They are not attributed to that commit in particular. They are traced all the way up to that commit, so they are either from this commit or from an earlier one.

Show 9 quoted lines

> But I find it really misleading, as this is the true picture if we
> dug to the bottom of the history:
>
>     $ git blame -L103,107 v2.0.0-rc2 t/t9117-git-svn-init-clone.sh
>     f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 103) 
>     7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_...
>     f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 105)  test ! -d p...
>     7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106)  git svn ini...
>     f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 107)  test_must_f...

So indeed, an earlier one.

> I do not expect Johan's name to appear in the output for the first
> one, because that would require us to dig deeper than the commit we
> were told to stop at, but I am wondering if we can do better than the
> existing "-b" option to reduce the confusion from the output.

Do you mean "better than" or rather "better in the case where -b is given"?

Show 30 quoted lines

> The "-b" option blanks the commit object name, but still shows the
> name and timestamp for the bottom commit:
>
>              (Junio C Hamano 2014-04-18 11:21:43 -0700 103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>              (Junio C Hamano 2014-04-18 11:21:43 -0700 105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>              (Junio C Hamano 2014-04-18 11:21:43 -0700 107)         test...
>
> I am tempted to say "blame that is run without the --porcelain
> option is a end-user facing Porcelain, and people should not be
> reading its output in their scripts" and change the behaviour of the
> "-b" option to instead show something like this instead:
>     
>     ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>     ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>     ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 107)         test...
>
> which shows the commit object name, its bottom-ness and the
> timestamp, or even
>
>              (                                         103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>              (                                         105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>              (                                         107)         test...
>
> which does away with the misleading information altogether.

That would make more sense for -b but hardly for the default.

> I myself is leaning towards the latter between the two, and not
> overriding "-b" but introducing another "cleanse the output of
> useless bottom information even more" option.

One could use -b -b but frankly, where is the point? Name and date deliver no useful information when the commit is absent.

-- 
David Kastrup

Junio C Hamano· May 8, 2014, 21:56 UTC · re: David Kastrup · lore

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

In short:

 - I am not considering nor proposing to change the default at all.

 - I have two choices, either change the behaviour of "-b", or
   introducing a new option (the latter includes "-b -b"); I am
   slightly in favor of the latter, but not by a large margin.

 - I have two choices, regardless of how the new mode is triggered,
   for outputs.  Either fill it with "Unknown" name and leave
   everything else as is, or blank all information from the boundary
   commit out.  I am moderately in favor of the latter.

Hope that clarifies.

Jeff King· May 9, 2014, 01:55 UTC · re: Junio C Hamano · lore

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

On Thu, May 08, 2014 at 02:56:46PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> In short:
> 
>  - I am not considering nor proposing to change the default at all.
> 
>  - I have two choices, either change the behaviour of "-b", or
>    introducing a new option (the latter includes "-b -b"); I am
>    slightly in favor of the latter, but not by a large margin.
> 
>  - I have two choices, regardless of how the new mode is triggered,
>    for outputs.  Either fill it with "Unknown" name and leave
>    everything else as is, or blank all information from the boundary
>    commit out.  I am moderately in favor of the latter.
> 
> Hope that clarifies.

Thanks, that makes it much more clear to me at least what you were asking in the original.

Not that my opinion necessarily matters, but what I was trying to express elsewhere in the thread was a preference for: output is blank, and tie it to "-b" (mostly because I do not see any way in which the author name sans commit is at all useful).

I _would_ consider changing the default to "-b", but that is really a separate topic from this (and quite possibly falls under the "if I were designing from scratch today, but I am not..." category of changes).

-Peff

Jeff King· May 8, 2014, 21:26 UTC · re: Junio C Hamano · lore

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

On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

>              (                                         103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>              (                                         105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>              (                                         107)         test...
> 
> which does away with the misleading information altogether.
> 
> I myself is leaning towards the latter between the two, and not
> overriding "-b" but introducing another "cleanse the output of
> useless bottom information even more" option.

Though I rarely use boundary commits, this one makes the most sense to me (when I do use them, I just mentally assume that the information in the boundary line is useless; this is just making that more apparent).

Coincidentally, I recently came across a malformed commit that had a bogus empty committer name and email. The "git log" pretty-printer omits the author and committer lines entirely. "blame" will show "(unknown)" in the name field. I wonder if it should also switch to a formatted blank as above (but _do_ print the commit).

-Peff

David Kastrup· May 8, 2014, 21:32 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

> On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote:
>
>>              (                                         103) 
>>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>>              (                                         105)         test...
>>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>>              (                                         107)         test...
>> 
>> which does away with the misleading information altogether.
>> 
>> I myself is leaning towards the latter between the two, and not
>> overriding "-b" but introducing another "cleanse the output of
>> useless bottom information even more" option.
>
> Though I rarely use boundary commits, this one makes the most sense to
> me (when I do use them, I just mentally assume that the information in
> the boundary line is useless; this is just making that more apparent).

It is unclear to me what "this one makes the most sense to me" is referring to, in particular whether it encompasses the "and not overriding" part of the paragraph.

-- 
David Kastrup

Jeff King· May 9, 2014, 00:11 UTC · re: David Kastrup · lore

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

On Thu, May 08, 2014 at 11:32:01PM +0200, David Kastrup wrote:

Show 23 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote:
> >
> >>              (                                         103) 
> >>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
> >>              (                                         105)         test...
> >>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
> >>              (                                         107)         test...
> >> 
> >> which does away with the misleading information altogether.
> >> 
> >> I myself is leaning towards the latter between the two, and not
> >> overriding "-b" but introducing another "cleanse the output of
> >> useless bottom information even more" option.
> >
> > Though I rarely use boundary commits, this one makes the most sense to
> > me (when I do use them, I just mentally assume that the information in
> > the boundary line is useless; this is just making that more apparent).
> 
> It is unclear to me what "this one makes the most sense to me" is
> referring to, in particular whether it encompasses the "and not
> overriding" part of the paragraph.

Sorry, I should have been more clear. I meant that the output format shown there makes the most sense of the ones shown.

I'd actually be inclined to say the opposite of what Junio is saying there: that "-b" should blank the author field as well as the commit sha1. I'd even go so far as to say that "-b" should probably be the default when boundary commits are in use. I cannot think of a time when I have found the boundary information useful, and the IMHO the output above is less confusing than what we produce now. But I admit I haven't thought very hard on it.

-Peff

David Kastrup· May 9, 2014, 05:04 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

> I'd actually be inclined to say the opposite of what Junio is saying
> there: that "-b" should blank the author field as well as the commit
> sha1. I'd even go so far as to say that "-b" should probably be the
> default when boundary commits are in use. I cannot think of a time when
> I have found the boundary information useful, and the IMHO the output
> above is less confusing than what we produce now. But I admit I haven't
> thought very hard on it.

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

-- 
David Kastrup

Jeff King· May 9, 2014, 15:29 UTC · re: David Kastrup · lore

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

On Fri, May 09, 2014 at 07:04:05AM +0200, David Kastrup wrote:

Show 6 quoted lines

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

-Peff

Junio C Hamano· May 9, 2014, 17:28 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

> 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 ;-).

We may want to flip the default to do a more sanitised version of "-b" that has been suggested earlier:

Show 7 quoted lines

>              (                                         103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>              (                                         105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>              (                                         107)         test...
> 
> which does away with the misleading information altogether.

and have another option to show the current default output for those who would want that information.

But that will be a topic for post 2.0; I should start preparing for the -rc3 soonish, so I'll stop here.

David Kastrup· May 9, 2014, 19:59 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:

Show 25 quoted lines

> Jeff King <peff@peff.net> 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

Duy Nguyen· May 10, 2014, 13:45 UTC · re: David Kastrup · lore

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

On Fri, May 9, 2014 at 12:04 PM, David Kastrup <dak@gnu.org> wrote:

Show 16 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> I'd actually be inclined to say the opposite of what Junio is saying
>> there: that "-b" should blank the author field as well as the commit
>> sha1. I'd even go so far as to say that "-b" should probably be the
>> default when boundary commits are in use. I cannot think of a time when
>> I have found the boundary information useful, and the IMHO the output
>> above is less confusing than what we produce now. But I admit I haven't
>> thought very hard on it.
>
> 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).

No it's not. The idea of shallow repos is to work like a normal repo (most of the time at least). Excluding git-blame from shallow repos is a bad idea. Luckily it's not hard to detect shallow boundaries: if a commit has no parents and lookup_commit_graft() returns -1, then that's it.

-- 
Duy

John Keeping· May 8, 2014, 21:38 UTC · re: Junio C Hamano · lore

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

On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote:

Show 25 quoted lines

> I am tempted to say "blame that is run without the --porcelain
> option is a end-user facing Porcelain, and people should not be
> reading its output in their scripts" and change the behaviour of the
> "-b" option to instead show something like this instead:
>     
>     ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>     ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>     ^cc29195 (Unknown        2014-04-18 11:21:43 -0700 107)         test...
> 
> which shows the commit object name, its bottom-ness and the
> timestamp, or even
> 
>              (                                         103) 
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>              (                                         105)         test...
>     7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
>              (                                         107)         test...
> 
> which does away with the misleading information altogether.
> 
> I myself is leaning towards the latter between the two, and not
> overriding "-b" but introducing another "cleanse the output of
> useless bottom information even more" option.

I'd be tempted to leave the SHA-1 to indicate "sometime before" but delete the author and date (I also think it looks a bit nicer to omit the opening parenthesis):

    ^cc29195                                           103) 
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
    ^cc29195                                           105)         test...
    7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106)         git ...
    ^cc29195                                           107)         test...

On a slight tangent, I tried this in a fairly young repository and got this (with master at v2.0.0-rc2-4-g1dc51c6):

$ git blame Makefile | head -5 7a3fc144 (John Keeping 2013-12-26 17:37:53 +0000 1) REL_VERSION = v0.2 5c9829f9 (John Keeping 2013-07-29 17:03:26 +0100 2) 5c9829f9 (John Keeping 2013-07-29 17:03:26 +0100 3) # The default target is... ^f7fae99 (John Keeping 2013-03-24 17:14:40 +0000 4) all:: ^f7fae99 (John Keeping 2013-03-24 17:14:40 +0000 5)

f7fae99 is the initial commit in the repository, so shouldn't the last two lines blame to that, not a non-existent ancestor?

Junio C Hamano· May 8, 2014, 21:58 UTC · re: John Keeping · lore

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

John Keeping <john@keeping.me.uk> writes:

Show 12 quoted lines

> On a slight tangent, I tried this in a fairly young repository and got
> this (with master at v2.0.0-rc2-4-g1dc51c6):
>
> $ git blame Makefile | head -5
> 7a3fc144 (John Keeping      2013-12-26 17:37:53 +0000   1) REL_VERSION = v0.2
> 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   2) 
> 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   3) # The default target is...
> ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   4) all::
> ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   5) 
>
> f7fae99 is the initial commit in the repository, so shouldn't the last
> two lines blame to that, not a non-existent ancestor?

It is not saying f7fae99^, is it? It is debatable if it is correct to mark the root commit as a boundary, but that is what it is showing, I think. In other words, "this line hasn't changed since the inception of the project".

John Keeping· May 8, 2014, 22:10 UTC · re: Junio C Hamano · lore

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

On Thu, May 08, 2014 at 02:58:58PM -0700, Junio C Hamano wrote:

Show 19 quoted lines

> John Keeping <john@keeping.me.uk> writes:
> 
> > On a slight tangent, I tried this in a fairly young repository and got
> > this (with master at v2.0.0-rc2-4-g1dc51c6):
> >
> > $ git blame Makefile | head -5
> > 7a3fc144 (John Keeping      2013-12-26 17:37:53 +0000   1) REL_VERSION = v0.2
> > 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   2) 
> > 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   3) # The default target is...
> > ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   4) all::
> > ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   5) 
> >
> > f7fae99 is the initial commit in the repository, so shouldn't the last
> > two lines blame to that, not a non-existent ancestor?
> 
> It is not saying f7fae99^, is it?  It is debatable if it is correct
> to mark the root commit as a boundary, but that is what it is
> showing, I think.  In other words, "this line hasn't changed since
> the inception of the project".

Yes, it's marking it as a boundary but I'm not convinced that's correct. Compare these two cases:

$ git blame ^5c9829f9 Makefile | head -5 7a3fc144 (John Keeping 2013-12-26 17:37:53 +0000 1) REL_VERSION = v0.2 ^5c9829f (John Keeping 2013-07-29 17:03:26 +0100 2) ^5c9829f (John Keeping 2013-07-29 17:03:26 +0100 3) # The default target is... ^5c9829f (John Keeping 2013-07-29 17:03:26 +0100 4) all:: ^5c9829f (John Keeping 2013-07-29 17:03:26 +0100 5)

While it might be useful to mark the initial commit, the current output seems to mean that lines 4 and 5 existed before the repository was created. If you consider blame's output to mean "introduced by commit" then those lines should simply blame to the initial commit.

`git log --boundary` does not mark the initial commit as a boundary.

John Keeping· May 8, 2014, 22:16 UTC · re: John Keeping · lore

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

On Thu, May 08, 2014 at 11:10:24PM +0100, John Keeping wrote:

Show 22 quoted lines

> On Thu, May 08, 2014 at 02:58:58PM -0700, Junio C Hamano wrote:
> > John Keeping <john@keeping.me.uk> writes:
> > 
> > > On a slight tangent, I tried this in a fairly young repository and got
> > > this (with master at v2.0.0-rc2-4-g1dc51c6):
> > >
> > > $ git blame Makefile | head -5
> > > 7a3fc144 (John Keeping      2013-12-26 17:37:53 +0000   1) REL_VERSION = v0.2
> > > 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   2) 
> > > 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   3) # The default target is...
> > > ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   4) all::
> > > ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   5) 
> > >
> > > f7fae99 is the initial commit in the repository, so shouldn't the last
> > > two lines blame to that, not a non-existent ancestor?
> > 
> > It is not saying f7fae99^, is it?  It is debatable if it is correct
> > to mark the root commit as a boundary, but that is what it is
> > showing, I think.  In other words, "this line hasn't changed since
> > the inception of the project".
> 
> Yes, it's marking it as a boundary but I'm not convinced that's correct.

But it is intentional. I get the output I expect if I use `git blame --root`.

Junio C Hamano· May 8, 2014, 22:31 UTC · re: John Keeping · lore

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

John Keeping <john@keeping.me.uk> writes:

Show 22 quoted lines

> Yes, it's marking it as a boundary but I'm not convinced that's correct.
> Compare these two cases:
>
> $ git blame Makefile | head -5
> 7a3fc144 (John Keeping      2013-12-26 17:37:53 +0000   1) REL_VERSION = v0.2
> 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   2) 
> 5c9829f9 (John Keeping      2013-07-29 17:03:26 +0100   3) # The default target is...
> ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   4) all::
> ^f7fae99 (John Keeping      2013-03-24 17:14:40 +0000   5) 
>
> $ git blame ^5c9829f9 Makefile | head -5
> 7a3fc144 (John Keeping      2013-12-26 17:37:53 +0000   1) REL_VERSION = v0.2
> ^5c9829f (John Keeping      2013-07-29 17:03:26 +0100   2) 
> ^5c9829f (John Keeping      2013-07-29 17:03:26 +0100   3) # The default target is...
> ^5c9829f (John Keeping      2013-07-29 17:03:26 +0100   4) all::
> ^5c9829f (John Keeping      2013-07-29 17:03:26 +0100   5) 
>
>
> While it might be useful to mark the initial commit, the current output
> seems to mean that lines 4 and 5 existed before the repository was
> created.  If you consider blame's output to mean "introduced by commit"
> then those lines should simply blame to the initial commit.

You may be onto something, but I am not sure. Let me, as you told me to, compare these two outputs.

The first says "At f7fae99, these lines were already there, and we are not showing anything before that state." The second says exactly the same thing but with f7fae99 replaced with 5c9829f.

It is debatable if a root commit is *that* special to be shown differently from an in-between commit that introduced a change, and for consistency, I tend to agree with you that it may be better if roots weren't marked with the "^" prefix.