From: Junio C Hamano <gitster@pobox.com>
To: David Howells <dhowells@redhat.com>
Cc: Valerie Aurora <valerie.aurora@gmail.com>,
"git\@vger.kernel.org" <git@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: How best to handle multiple-authorship commits in GIT?
Date: Fri, 03 Feb 2012 10:27:56 -0800 [thread overview]
Message-ID: <7vty37rcur.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4681.1328276820@redhat.com> (David Howells's message of "Fri, 03 Feb 2012 13:47:00 +0000")
David Howells <dhowells@redhat.com> writes:
> Valerie Aurora <valerie.aurora@gmail.com> wrote:
>
>> And for a complete (meaningful) rewrite such as David has done, he
>> changes the commit authorship and adds a Signed-off-by for the
>> original author.
>
> Val[*] hasn't signed off all her patches, and indeed I've merged together some
> patches that she has signed off and some she hasn't. I can't simply add
> Signed-off-by her without her permission. However, if she's willing for me to
> add such lines, then I can do so.
>
>> Signed-off-by: Some Upstream Author
>> Signed-off-by: Maintainer or Merger (rewrote error handling)
>
> And if the changes are more than can be put in what's left of the line? I
> would've thought it would make more sense to do something like:
>
> Signed-off-by: Valerie Aurora <valerie.aurora@gmail.com> (Original author)
> Signed-off-by: David Howells <dhowells@redhat.com> (Further development)
>
> David
That all sounds sensible.
I personally think the "recognition" factor Valerie alluded to in one of
her earlier message is a real and important issue, but I do not think
adding arbitrary number of "author" headers to the commit object would
help very much to solve it, for various reasons:
* While we made it easy to run "git shortlog -s -n --since=3.months" and
congratulate himself with "I now am the third most active person!" for
anybody, Git itself does not ship an equally easy way to analyze other
kinds of contributions to your project. I am merely a bystander, but
if I recall correctly, there were discussions on how to recognize
contributions by bug-reporters and testers using the history stored in
Git on the kernel list. The types of contribution you would want to
recognize however would be different from project to project. For that
kind of analysis, you would be better off doing something like what
lwn.net does, mining the text from the message part of the log.
* Even if we limit the issue to "who wrote X" (replace X with the name of
any piece of software), taking "author" field as anything more than an
approximation would be asking for a trouble. Not all patches are of
equal impact and importance.
* You would also have to think about how you would present "git shortlog"
output if you updated Git to record more than one "author" field in the
commit header. If Valerie wrote 27 patches by herself, 33 patches
together with you sitting next to each other, 17 patches with somebody
else, how would the entries for her, you and the third person look
like? Or would combinations of "Valerie & David", "Valerie & the
third person", etc. have separate entries in the output?
In short, I would say that you should take the name recorded in the
"author" field nothing more than the primary contact for a particular
commit to be used in case others have question on it later.
next prev parent reply other threads:[~2012-02-03 18:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 12:25 How best to handle multiple-authorship commits in GIT? David Howells
2012-02-02 13:41 ` Frans Klaver
2012-02-02 18:00 ` Valerie Aurora
2012-02-02 19:57 ` Jakub Narebski
2012-02-02 18:36 ` David Howells
2012-02-03 2:18 ` Valerie Aurora
2012-02-03 5:11 ` Junio C Hamano
2012-02-03 13:47 ` David Howells
2012-02-03 18:27 ` Junio C Hamano [this message]
2012-02-03 19:49 ` Valerie Aurora
2012-02-02 20:33 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vty37rcur.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=dhowells@redhat.com \
--cc=git@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=valerie.aurora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).