Re: co-authoring commits

[Junio C Hamano <gitster@pobox.com>]

josh@joshtriplett.org writes:

> Having more than one author field in a commit would likely break things,
> but having a coauthor field seems plausible these days.  Git added
> support for signed commits, and the world didn't end, so it's possible
> to extend the commit format.

Something being possible and something being sensible are two
different things, though.

I agree "coauthor field that is not understood by anybody" would
unlikely break existing implementations, but it is not a useful way
to add this information to commit objects.  For one thing, until you
teach "git log" or its equivalents in everybody's (re)implementation
of Git, the field will not be shown, you cannot easily edit it while
amending or rebasing, "git log --grep=" would not know about it, and
you would need "git cat-file commit" to view it.

A footer Co-authored-by: does not have any such issue.

We left commit headers extensible long before we introduced commit
signing, and we used it to add the "encoding" header.  In general,
we invent new headers only when structurely necessary.  When you
declare that the log message for this indiviaul commit is done in
one encoding, that is not something you would want to _edit_ with
your editor while you are editing your message.  Similarly you would
not want to risk touching the GPG signature of a signed commit or a
signed merge while editing your message.

The _only_ reason I would imagine why somebody may be tempted to
think that "coauthor" as part of the object header makes sense is
because "author" is already there.  You can argue that "author" did
not have to be part of the object header, and that is right.  I
would agree with you 100% that "author" did not have to be there.

But that is too late to change.

And being consistent with a past mistake is not a good reason to
repeat that same mistake.