On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx> 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
>> 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).