Re: co-authoring commits

From: josh@joshtriplett.org <josh@joshtriplett.org>
Date: Jun 17, 2015, 22:28 UTC
Message-ID: <20150617222828.GB24438@cloud>
In-Reply-To: <xmqqegla57hl.fsf@gitster.dls.corp.google.com>

On Wed, Jun 17, 2015 at 02:51:18PM -0700, Junio C Hamano wrote:

Show 19 quoted lines

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

Sure it does; while it would display in raw form because it's a part of the commit message, you'd still have to teach "git log --author" about it (git grep is not a substitute), map it through mailmap, teach git shortlog about it, teach send-email and format-patch to use it in mail headers, teach repository statistics tools about it, and in general teach every tool that reads the "author" field of a commit to handle co-authors. And if it's a pseudo-field in the commit, you'd also have to have more complex parsing rules to find and parse it.

Git has almost no understanding of in-band magic "headers" in a commit message. It has a bit of support for generating (but not parsing) Signed-off-by, and send-email has some support for adding *-by headers to Cc, but a pseudo-header that git tools actually *parse* out of the commit message would be a first.

Show 14 quoted lines

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

Author and committer are used by many git tools; if they weren't part of the object header, they'd need to be part of some pseudo-header with a standardized format that git can parse.

- Josh Triplett