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:

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

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

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