On Wed, Jun 17, 2015 at 11:51 PM, Junio C Hamano wrote: > j...@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.
Makes sense. Without intimate knowledge of current internals, what about the following potentially crazy plan? 1. demote/deprecate GIT_AUTHOR_* 2. implement a new author-ship model that supports both and treats the old entries as supported-but-deprecated 3. maybe auto-migrate entries in the repo, or add a switch to do that as part of git-gc or another process 4. extend tooling to support 'commit --add-author' or similar 5. teach git.git tools to properly display additional authors as equals in commit ownership 6. let other tools catch up, but rest assured nothing was broken 7. consider other use cases and different implementations (flexibility), to not have to repeat this 5 years down the road for another field -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
