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

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?

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

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

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

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?