josh@xxxxxxxxxxxxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html