Re: co-authoring commits

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