I fairly often work on a commit with other people, and I want the
commit metadata to reflect that by showing multiple authors for one
commit.  Multiple people can sign off on one commit, but when such a
patch merges upstream you cannot distinguish that from a chain of
signoffs.  Furthermore, I want something machine-readable and
consistent, like the current metadata.

RFCs 822 and 2822 allow mail messages to contain multiple addresses in
the From field, which suitably describes a message with multiple
authors.  (In such messages, the Sender field must describe who
actually sent the mail.)  Based on this, I would like Git to do the
following:

* When applying patches from mails with multiple From addresses,
  generate a commit with multiple authors.

* When formatting a patch from a commit with multiple authors,
  generate a mail with multiple From addresses, and use the current
  Git identity as the Sender.  (Actually, generating the Sender field
  using the current identity potentially makes sense regardless, if
  not the same as the committer.)

* Let me specify a commit with multiple authors via git-commit, such
  as by specifying multiple --author options.

I think the primary issue here lies with backward compatibility in the
format of a commit object.  I *think* some extensibility exists there,
sufficient to implement this.

- Josh Triplett

reassign 451880 git git-core/1:1.5.3.5-1
found 451880 git/1:1.7.1-1
tags 451880 + upstream
quit

Hi Josh,

Josh Triplett wrote[1]:

This has come up a few times recently[2][3][4], with the best workaround
suggested being Andreas’s

  Co-authored-by: Some One <some.one@example.foo>

As you mentioned, emails are allowed to have multiple authors, and
there is no reason in principle some faraway future git version could
not similarly handle them:

 1. Teach _everyone_ who parses git objects (in git.git and elsewhere)
    to process ‘coauthor’ lines after the committer line.  Unlike
    the ‘author’ line, these would not have a date attached.

 2. Teach ‘git fsck’ (and hence index-pack, etc) to warn about them but
    not error out.

 3. Add a configuration variable to allow git to produce
    multiple-author commits.  Such commits would make the repository
    unusable by versions of git without (1) and (2), so probably nobody
    would want to enable this for a while.

Sounds doable but a lot of trouble.  Maybe Nicolas Pitre or Shawn Pearce
could say more if you want to pursue this.

Alternatively, maybe format-patch, fast-import/fast-export, and am
should cheat by processing Co-authored-by lines at the top of the final
paragraph of the commit message themselves.

BTW, thanks for all your work on git.  Your bug reports are a lot of
fun to read.

What do you think?
Jonathan

[1] http://bugs.debian.org/451880
[2] http://thread.gmane.org/gmane.comp.version-control.git/83880
[3] http://thread.gmane.org/gmane.comp.version-control.git/146086/focus=146223
[4] http://thread.gmane.org/gmane.comp.version-control.git/146886

I do something similar; all my pair-programmed commits have a note at
the end of the commit message saying
Commit by Josh Triplett and Jamey Sharp.

I'd just like git to have real metadata for this case.

I'd suggest just using multiple "author" lines for this, for two
reasons:

- Some tools might already handle this in a sensible way without
  breaking.  For instance, git show and git log seem to do the right
  thing already.

- It seems odd to have one author listed as "author" and others as
  "coauthor".

Also, I don't see any reason not to have the date attached to each
author; it can contain the same date, or under some circumstances it
might make sense for it to contain a different date.  And that way,
tools designed to parse "author" will not need to allow for the lack of
a date.

Multiple "committer" fields seems like an equally reasonable thing to
add support for at the same time, by the way.

git fsck seems to work just fine with multiple author fields in a
commit.

git fast-import needs fixing, though; it currently crashes if given
multiple author fields.

Agreed; the usual backward-compatibility delay.

Even with Git's current support for Signed-off-by, it still makes a
point of generally not parsing the commit message in any way.  That
seems like a feature worth preserving.

Thanks!  Always nice to hear. :)

I have this on my long-term TODO list to implement at some point, when I
scrounge up enough round tuits. :)

- Josh Triplett