From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: David Kastrup <dak@gnu.org>, git@vger.kernel.org
Subject: Re: Output from "git blame A..B -- path" for the bottom commit is misleading
Date: Fri, 09 May 2014 10:28:19 -0700 [thread overview]
Message-ID: <xmqqy4yazwss.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140509152935.GD18197@sigill.intra.peff.net> (Jeff King's message of "Fri, 9 May 2014 11:29:35 -0400")
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 ;-).
We may want to flip the default to do a more sanitised version of "-b"
that has been suggested earlier:
> ( 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.
next prev parent reply other threads:[~2014-05-09 17:28 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
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 [this message]
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=xmqqy4yazwss.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.