Re: Does it make sense to show tips on blame?

From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Date: Jan 22, 2017, 22:59 UTC
Message-ID: <CAOc6etbCLju8nUcU5SMOJwzAcjk_LM041Tak897XrXUpFWtCiA@mail.gmail.com>
In-Reply-To: <xmqqefzuvijl.fsf@gitster.mtv.corp.google.com>

On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:
>
> What does the word "tip" mean in this context?  The word is often
> used to mean the commits directly pointed at by branches (i.e. the
> tip of history), but I do not think that is what you are interested
> in showing in this butchered "diff" output.

Show 7 quoted lines

>
> Do you mean the one-line summary for the commit?  The commits that
> are shown will not be at the tip most of the time (the "+" ones may
> be if you happen to be running "git show" on the tip of a branch,
> but that is minority if you also want to do "git log -p"), so I am
> not sure it makes sense to call them "tips" in the above output.
>

Yeah, it would be the 1-line summary for the revision that is related to the lines that will be printed right after the summary, as a way to provide additional context about those lines without having to resort to an additional git show --summary command. Perhaps a name more appropriate name than "tips" in the context of git would be better suited to avoid confusion.

Show 11 quoted lines

> If I were doing the above, I would probably do them as footnotes to
> keep the body of the patch text (slightly) more readable.  E.g.
>
>         @@ -l,k +m,n @@
>          2a113aee9b
>         +405d7f4af6   if (!root-tree)
>         +405d7f4af6       load_tree(root)
>          ...
>         #2a113aee9b "fast-import: Proper notes tree manipulation", 2009-12-07
>         #405d7f4af6 "fast-import: properly fanout notes when tree is imported", 2016-12-21
>

Now, this is a different topic altogether (difflame related) and I think it was raised from the fact that I included output from difflame (which starts from diff output) as my example. When talking about blame it would be no-patches, just plain blame output writing the 1-line summary for blocks of lines related to the same revision. I already sent a patch today with the changes needed to see what I mean in action. Could you give it a test drive? Consider it's a rough draft (and I also raise the question of "aggregating" output on the mail thread)

Something like this, hope this doesn't get butchered (at least not that hard, i'm truncating the lines):

        3d426842: README.txt
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600   1) difflame
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600   2)
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600   3) Copyright 2017
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600   4) Released unde
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600   5)
       0660083e: Add params to blame and diff, adjust README.txt
0660083e (Edmundo Carmona Antoranz 2017-01-18 20:51:12 -0600   6) Show the outp
0660083e (Edmundo Carmona Antoranz 2017-01-18 20:51:12 -0600   7)
       c869edc9: README.txt - stick (or at least, at least try) to 80 columns
c869edc9 (Edmundo Carmona Antoranz 2017-01-20 23:39:51 -0600   8) Example outp
c869edc9 (Edmundo Carmona Antoranz 2017-01-20 23:39:51 -0600   9) params to cha

Show 10 quoted lines

>> The question is if you think it makes sense to add this option to
>> git-blame itself.
>>
>> Something like:
>> git blame --tips README.txt
>
> I do not think I would use it personally, as it would make it hard
> to pipe the output of "git blame" to less and then /search things,
> as extra cruft added by the option will get in the way.  IOW, I do
> not think we want it for human-oriented output.

Doing a search through less, it would make sense to leave the 1-line summary out but when looking at blame output through OSI layer 8, I'd definitely like to get that 1-line summary "as an option" every so often (more often than not in my case, probably).