git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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