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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: David Kastrup <hidden>
Date: 2016-06-15 23:01:03

Jeff King [off-list ref] writes:
On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote:
quoted
             (                                         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

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

From: Jeff King <hidden>
Date: 2016-06-15 23:01:04

On Thu, May 08, 2014 at 11:32:01PM +0200, David Kastrup wrote:
Jeff King [off-list ref] writes:
quoted
On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote:
quoted
             (                                         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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help