Re: [PATCH/RFC] fmt-merge-msg: add a blank line after people info

Linus Torvalds [off-list ref] writes:

On Tue, May 15, 2012 at 1:24 PM, Junio C Hamano [off-list ref] wrote:

quoted

Now, computing this efficiently may not be trivial, as you would need N^2
reachability analysis when pulling in N commits. Among 2000 recent merges
I sampled from the kernel history, 70+ pull in more than 1000 commits (the
largest one d4bbf7e77 pulls in 21k commits).

So I have to say, for my purposes, it not only might be inefficient,
but it can still be very misleading.
...
(Admittedly, so it the shortlog we put in the merge, so that "you can
find it later in the git tree itself" not *that* great of an argument
- the real argument for me is that it doesn't matter what you count,
you'll not necessarily get the actual piece of information I care
about..).

There is no way to mine "X pulled from Y" out of the topology if you allow
fast-forward anywhere, so "I care about whom I pulled from" is something
people need to give out of band.  Your lieutenant may have fast-forwarded
his history from his lieutenant's, or you may even be fast-forwarding your
history from your lieutenant's, in which case you do not even have a merge
commit to record that fact anyway.  If you do not fast-forward, at least
the merge subject would give you where you got the history from, so it is
not like that the information *must* be obtained by looking at the history
anyway (incidentally, that was the reason why the "better than random
number generator but not by a large margin" version gives an extra weight
to the tip commit you are pulling; unless your lieutenant fast-forwarded,
that is the person you pulled from).

So I'm not entirely convinced yet. I don't *dislike* the concept, but
I could definitely do without it (or maybe have it in the commented
part of the commit message, so that you'd have to explicitly edit it
to show up).

I am tempted to suggest removing the "via" part as a failed experiment for
now.