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

[Junio C Hamano <gitster@pobox.com>]

Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:

> Output is like this (from README.txt, taken from difflame on git
> itself, sorry if it's too wide):

It is not just too wide but it is line-wrapped and cannot see what
you wanted to say out of it.

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.

> 2a113aee9b (Johan Herland 2009-12-07 12:27:24 +0100 2227)
>         405d7f4af fast-import: properly fanout notes when tree is imported
> +405d7f4af6 (Mike Hommey   2016-12-21 06:04:48 +0900 2228)      if (!root->tree)
> +405d7f4af6 (Mike Hommey   2016-12-21 06:04:48 +0900 2229)
>  load_tree(root);
> ...

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.

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

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

On the other hand, when output from "blame" is used by scripts (or
GUI frontends), having the one-line summary would be very useful.
But I think the authors of "blame" already thought about that
usecase and included the "summary" field in the "--porcelain" output
that are meant to be consumed by scripts, so...