git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: How best to handle multiple-authorship commits in GIT?

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 3, 2012, 18:27 UTC
Message-ID
<7vty37rcur.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4681.1328276820@redhat.com>
David Howells <dhowells@redhat.com> writes:
Show 21 quoted lines
> 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.

Previous: David HowellsNext: Valerie Aurora
Message 9 of 11 in “How best to handle multiple-authorship commits in GIT?”
  1. David HowellsFeb 2, 2012
  2. Frans KlaverFeb 2, 2012
  3. David HowellsFeb 2, 2012
  4. Valerie AuroraFeb 2, 2012
  5. David HowellsFeb 2, 2012
  6. Valerie AuroraFeb 3, 2012
  7. Junio C HamanoFeb 3, 2012
  8. David HowellsFeb 3, 2012
  9. Junio C HamanoFeb 3, 2012
  10. Valerie AuroraFeb 3, 2012
  11. Jakub NarebskiFeb 2, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.