From: David Kastrup <dak@gnu.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Output from "git blame A..B -- path" for the bottom commit is misleading
Date: Thu, 08 May 2014 23:13:31 +0200 [thread overview]
Message-ID: <878uqcotxg.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <xmqq8uqc2dt5.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Thu, 08 May 2014 13:52:38 -0700")
Junio C Hamano <gitster@pobox.com> 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
next prev parent reply other threads:[~2014-05-08 21:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 20:52 Output from "git blame A..B -- path" for the bottom commit is misleading Junio C Hamano
2014-05-08 21:13 ` David Kastrup [this message]
2014-05-08 21:56 ` Junio C Hamano
2014-05-09 1:55 ` Jeff King
2014-05-08 21:26 ` Jeff King
2014-05-08 21:32 ` David Kastrup
2014-05-09 0:11 ` Jeff King
2014-05-09 5:04 ` David Kastrup
2014-05-09 15:29 ` Jeff King
2014-05-09 17:28 ` Junio C Hamano
2014-05-09 19:59 ` David Kastrup
2014-05-10 13:45 ` Duy Nguyen
2014-05-08 21:38 ` John Keeping
2014-05-08 21:58 ` Junio C Hamano
2014-05-08 22:10 ` John Keeping
2014-05-08 22:16 ` John Keeping
2014-05-08 22:31 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878uqcotxg.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).