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

On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano [off-list ref] wrote:

Edmundo Carmona Antoranz [off-list ref] 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.

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.

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

quoted

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