On Tue, May 15, 2012 at 1:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> 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.
I actually care most about the person I personally pull from. And if
he is a submaintainer who has other submaintainers, it can be that
following the commit history doesn't show him at *all*. He might have
done just a fast-forward merge, but he's still the person *I* want to
credit.
So I'm getting the feeling that the "count authors/committers" may be
cute, but it's not necessarily all that relevant. It's the kind of
information you can see later from the git tree itself.
(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..).
So I think it's somewhat interesting information, and I haven't really
disliked seeing it, but I have mostly edited it away (although I see
that some other maintainers also run modern versions of git and have
left it in place, so we do have those in the kernel).
The one merge commit of mine that has it, I edited it so that the "via
C Committer" was on the same lne as the "By A Author" information.
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).
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html