co-authoring commits

co-authoring commits

[Tuncer Ayaz]

Even though I don't have time to work on a feature like this, like
others before me, I've been in situations where I would have liked to
set more than one GIT_AUTHOR_NAME (etc.) for a single commit due to
the involvement of multiple developers in authoring a change.

Is this something that breaks the design and would never be implemented,
or can it be integrated such that one can specify co-authors when
committing a change?

I'm thinking:

$ git commit --add-author "Tony Zwei <elsegundo@example.com>"

Re: co-authoring commits

[Junio C Hamano]

Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:

> Is this something that breaks the design and would never be implemented,

Yes.

Re: co-authoring commits

[Tuncer Ayaz]

On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
> > Is this something that breaks the design and would never be
> > implemented,
>
> Yes.

Junio, thanks for the quick response.

I suppose things have changed since Jonathan Nieder's response in [1]
(2010), or I've read too much into the mini-thread between Jonathan
and Josh. I was under the impression that this is generally possible
without shaking up all underpinnings.

For what it's worth, here's why I would use the feature:

By allowing multiple authors, you don't have to decide who's the
primary author, as in such situations usually there is no primary at
all. I sometimes deliberately override the author when committing and
add myself just as another co-author in the commit message, but as
others have noted it would be really great if we can just specify
multiple authors.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880

Re: co-authoring commits

[Junio C Hamano]

Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:

> On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
>> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>>
>> > Is this something that breaks the design and would never be
>> > implemented,
>>
>> Yes.
>
> Junio, thanks for the quick response.
>
> I suppose things have changed since Jonathan Nieder's response in [1]
> (2010),...

I do not think there is anything changed.  Jonathan was being a bit
more diplomatic and academic than I am.

"There is no reason in principle some faraway future version of Git
could" is _always_ true as a mental masturbation without taking
reality into account, aka "Sounds doable but a lot of trouble" means
"it is doable but it is dubious that it is worth doing".

Re: co-authoring commits

[josh]

On Wed, Jun 17, 2015 at 01:57:12PM -0700, Junio C Hamano wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
> 
> > On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
> >> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
> >>
> >> > Is this something that breaks the design and would never be
> >> > implemented,
> >>
> >> Yes.
> >
> > Junio, thanks for the quick response.
> >
> > I suppose things have changed since Jonathan Nieder's response in [1]
> > (2010),...
> 
> I do not think there is anything changed.  Jonathan was being a bit
> more diplomatic and academic than I am.
> 
> "There is no reason in principle some faraway future version of Git
> could" is _always_ true as a mental masturbation without taking
> reality into account, aka "Sounds doable but a lot of trouble" means
> "it is doable but it is dubious that it is worth doing".

What happens in old versions of git if you try to look at a signed git
commit?  The same level of interoperability used there would work here,
with the additional property that this would be optional metadata so we
might be able to make read-only access work with older versions.

- Josh Triplett

Re: co-authoring commits

[josh]

On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
> > Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
> >
> > > Is this something that breaks the design and would never be
> > > implemented,
> >
> > Yes.
> 
> Junio, thanks for the quick response.
> 
> I suppose things have changed since Jonathan Nieder's response in [1]
> (2010), or I've read too much into the mini-thread between Jonathan
> and Josh. I was under the impression that this is generally possible
> without shaking up all underpinnings.
> 
> For what it's worth, here's why I would use the feature:
> 
> By allowing multiple authors, you don't have to decide who's the
> primary author, as in such situations usually there is no primary at
> all. I sometimes deliberately override the author when committing and
> add myself just as another co-author in the commit message, but as
> others have noted it would be really great if we can just specify
> multiple authors.

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.

- Josh Triplett

Re: co-authoring commits

[Junio C Hamano]

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.

Re: co-authoring commits

[Tuncer Ayaz]

On Wed, Jun 17, 2015 at 11:51 PM, Junio C Hamano wrote:
> 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.

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

Re: co-authoring commits

[josh]

On Wed, Jun 17, 2015 at 02:51:18PM -0700, Junio C Hamano wrote:
> 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.

> 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

Re: co-authoring commits

[Junio C Hamano]

josh@joshtriplett.org writes:

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

Yes, the same goes to the address on Signed-off-by: footers.  There
recently was a series to enhance the footer list handling (Christian
Cc'ed) for the generation and maintenance side, and I do think it is
reasonable to further add enhanced support for footers.

That does not argue for having a new "coauthor" as a new commit
object header at all, though.

Re: co-authoring commits

[Jakub Narębski]

Junio C Hamano wrote:
> josh@joshtriplett.org writes:
>
>> 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.
>
> Yes, the same goes to the address on Signed-off-by: footers.  There
> recently was a series to enhance the footer list handling (Christian
> Cc'ed) for the generation and maintenance side, and I do think it is
> reasonable to further add enhanced support for footers.
>
> That does not argue for having a new "coauthor" as a new commit
> object header at all, though.

The threshold for modifying commit object is high. This is an
ABI-level change, something to do if there is no other solution.

Author and committer include datetime in the contents of the
field, which is used by Git for heuristics limiting walk. Coauthor
would have the same date as author, isn't it? If, after long
and involved discussion, we didn't add 'generation' field (for
easier cutting history walking), what chance adding 'coauthor'
has.

OTOH it would be nice to have support for .mailmap, and for
grepping... but the former could conceivably be added to the trailer
tool, the latter can be done with appropriate regexp in
"git log --grep=...".

I wonder what would break if one used 'Name <e@mai.l>, Name <em@i.l>'
as the author...

-- 
Jakub Narębski

Re: co-authoring commits

[Jeff King]

On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:

> Author and committer include datetime in the contents of the
> field, which is used by Git for heuristics limiting walk. Coauthor
> would have the same date as author, isn't it? If, after long
> and involved discussion, we didn't add 'generation' field (for
> easier cutting history walking), what chance adding 'coauthor'
> has.

I don't think the two situations are comparable. I would (and did) argue
that a "generation" field is a bad header to bake in because of what it
means (it is redundant with the graph structure).

Whereas "co-author" is not a fundamentally bad; it's just not something
we chose to support early on, and it would have to be added now.

> OTOH it would be nice to have support for .mailmap, and for
> grepping... but the former could conceivably be added to the trailer
> tool, the latter can be done with appropriate regexp in
> "git log --grep=...".

I don't think we munge trailers during "git log" pretty-printing at all
now, but it is certainly something we could add (including mailmap-ing
them).  That doesn't seem like much more work than showing the co-author
field, and it's a lot more generally applicable (you could mailmap
S-O-B, Reviewed-by, and so forth).

Similarly, something like "git shortlog" would have to learn about
multiple authors under the "co-author" scheme. But likewise, it would
not be much more work to teach it something like:

  git shortlog --field=Reviewed-by

to handle an arbitrary trailer. And that is much more flexible.

> I wonder what would break if one used 'Name <e@mai.l>, Name <em@i.l>'
> as the author...

The "normal" parser we use for pretty-printing goes left-to-right and
will stop at the first ">", and show only the first author.

Older versions of git would then get the date wrong, complaining about
the ",". Newer versions parse the date from right-to-left to work around
such bogosities (especially things like "<foo <bar>>") and so will parse
back to the second ">".

Fsck will definitely complain about it.

-Peff

Re: co-authoring commits

[Jakub Narębski]

On 2015-06-19 at 06:25, Jeff King wrote:
> On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:
>> Author and committer include datetime in the contents of the
>> field, which is used by Git for heuristics limiting walk. Coauthor
>> would have the same date as author, isn't it? If, after long
>> and involved discussion, we didn't add 'generation' field (for
>> easier cutting history walking), what chance adding 'coauthor'
>> has.
> I don't think the two situations are comparable. I would (and did) argue
> that a "generation" field is a bad header to bake in because of what it
> means (it is redundant with the graph structure).
>
> Whereas "co-author" is not a fundamentally bad; it's just not something
> we chose to support early on, and it would have to be added now.
It is true that "generation" field is redundant with the graph
structure, but it is
not necessarily something bad. You don't avoid using red-black trees or
AVL trees
because they keep some _redundant_ "bookkeeping" data in the node structure.
Same for "generation" header: it is bookkeeping, but would make Git more
effective
(faster).

Though I don't think any distributed version control system store such
data in
their equivalent of commit objects... maybe Veracity (I didn't check)...
>> OTOH it would be nice to have support for .mailmap, and for
>> grepping... but the former could conceivably be added to the trailer
>> tool, the latter can be done with appropriate regexp in
>> "git log --grep=...".
> I don't think we munge trailers during "git log" pretty-printing at all
> now, but it is certainly something we could add (including mailmap-ing
> them).  That doesn't seem like much more work than showing the co-author
> field, and it's a lot more generally applicable (you could mailmap
> S-O-B, Reviewed-by, and so forth).
This is certainly something nice to have. Though for author and
committer (and also
for tagger if I remember it correctly) we have mailmap-aware and
not-mailmapped
versions. There isn't anything like that for trailers.
>
> Similarly, something like "git shortlog" would have to learn about
> multiple authors under the "co-author" scheme. But likewise, it would
> not be much more work to teach it something like:
>
>   git shortlog --field=Reviewed-by
>
> to handle an arbitrary trailer. And that is much more flexible.
It would also be nice to have something like this for blame... but at
least multiple
authors support doesn't make much sense wrt display uless using graphical
blame tool (like "git gui blame").
>
>> I wonder what would break if one used 'Name <e@mai.l>, Name <em@i.l>'
>> as the author...
> The "normal" parser we use for pretty-printing goes left-to-right and
> will stop at the first ">", and show only the first author.
>
> Older versions of git would then get the date wrong, complaining about
> the ",". Newer versions parse the date from right-to-left to work around
> such bogosities (especially things like "<foo <bar>>") and so will parse
> back to the second ">".
>
> Fsck will definitely complain about it.
Ah, that is a problem.

If I remember correctly, I have seen somewhere using Bob+Alice for the
name part
and <bob+alice@example.com> or <bob@emai.l+alice@em.ail> for the email
part...
Would this work, I wonder?

[hoping that Thunderbird email didn;t screw up formatting]
-- 
Jakub Narębski

Re: co-authoring commits

[Theodore Ts'o]

On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> 
> By allowing multiple authors, you don't have to decide who's the
> primary author, as in such situations usually there is no primary at
> all. I sometimes deliberately override the author when committing and
> add myself just as another co-author in the commit message, but as
> others have noted it would be really great if we can just specify
> multiple authors.

Just recently, there a major thread on the IETF mailing list where
IETF working group had drafts where people were listed as co-authors
without their permission, and were upset that the fact that their name
was added made it seem as if they agreed with the end product.  (i.e.,
that they were endorsing the I-D).  So while adding formal coauthor
might solves (a few) problems, it can also introduce others.

Ultimately there is one person who can decide which parts of the
changes to put in the commit that gets sent to the maintainer.  So
there *is* someone who is the primary author; the person who takes the
final pass on the patch and then hits the send key.

One could imagine some frankly, quite rare example where there is a
team of people who votes on each commit before it gets sent out and
where everyone is equal and there is no hierarchy.  In that case,
perhaps you could set the from field to a mailing list address.  But
honestly, how often is that *all* of the authors are completely
equal[1]?

In my personal practice, if I make significant changes to a patch, I
will indeed simply change the submitter, and then give credit the
original author.  This is the case where I'm essentially saying, "Bob
did a lot of work, but I made a bunch of changes, so if things break
horribly, blame *me*, not Bob".

Alternatively, if I just need to make a few cosmetic changes to
Alice's patch (i.e., fix white spaces, correct spelling, change the
commit description so it's validly parsable and understandable
English, etc.), I'll just add a comment in square brackets indicating
what changes I made before I committed the change.  This seems to work
just fine, and I don't think we should try to fix something that isn't
broken.

						- Ted


[1]  Gilbert and Sullivan attacked this notion is a commedic way in
"The Gondoliers"; especially in the songs "Replying we sing as one
individual" and "There Lived a King":

	     https://www.youtube.com/watch?v=YD0dgXTQ3K0
	     https://www.youtube.com/watch?v=oSaVdqcDgZc

Re: co-authoring commits

[josh]

On Wed, Jun 17, 2015 at 06:52:24PM -0400, Theodore Ts'o wrote:
> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> > 
> > By allowing multiple authors, you don't have to decide who's the
> > primary author, as in such situations usually there is no primary at
> > all. I sometimes deliberately override the author when committing and
> > add myself just as another co-author in the commit message, but as
> > others have noted it would be really great if we can just specify
> > multiple authors.
> 
> Just recently, there a major thread on the IETF mailing list where
> IETF working group had drafts where people were listed as co-authors
> without their permission, and were upset that the fact that their name
> was added made it seem as if they agreed with the end product.  (i.e.,
> that they were endorsing the I-D).  So while adding formal coauthor
> might solves (a few) problems, it can also introduce others.
> 
> Ultimately there is one person who can decide which parts of the
> changes to put in the commit that gets sent to the maintainer.  So
> there *is* someone who is the primary author; the person who takes the
> final pass on the patch and then hits the send key.

I've worked on many patches with another person in a shared screen
session, co-authoring a series of patches and commit messages in vim,
and writing an email in mutt.  There were, ultimately, two people
deciding what to put in a commit and send to the maintainer.  This is,
admittedly, unusual, but pair programming is not ridiculously uncommon.

> In that case, perhaps you could set the from field to a mailing list
> address.

The "From" field in email headers supports a list of comma-separated
addresses, just like To and Cc.  Speaking from experience, this
more-or-less works with all the mail software we tried it with, with the
occasional program only displaying the first or last entry.

- Josh Triplett

RE: co-authoring commits

[Jason Pyeron]

> -----Original Message-----
> From: Theodore Ts'o
> Sent: Wednesday, June 17, 2015 6:52 PM
> 
> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> > 
> > By allowing multiple authors, you don't have to decide who's the 
> > primary author, as in such situations usually there is no 
> primary at 
> > all. I sometimes deliberately override the author when 
> committing and 
> > add myself just as another co-author in the commit message, but as 
> > others have noted it would be really great if we can just specify 
> > multiple authors.
<snip/>
> One could imagine some frankly, quite rare example where 
> there is a team of people who votes on each commit before it 
> gets sent out and where everyone is equal and there is no 
> hierarchy.  In that case, perhaps you could set the from 
> field to a mailing list address.

This is a perfect use the signed commit by multiple persons. Git already
supports it (under the hood and in reporting).

A quick google pulled up my notes on this:

http://marc.info/?l=git&m=140845378317052&w=2

$ cat merge-multisigs.sh
#!/bin/bash
(
 for i in "$@"
 do
  gpg --dearmor < "$i"
 done
) | gpg --enarmor

$ cat write-commit.ruby
#!/usr/bin/irb
require 'fileutils'
file = File.open(ARGV[0], "rb")
content = file.read
header = "commit #{content.length}\0"
store = header + content
require 'digest/sha1'
sha1 = Digest::SHA1.hexdigest(store)
require 'zlib'
zlib_content = Zlib::Deflate.deflate(store)
path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
FileUtils.mkdir_p(File.dirname(path))
File.open(path, 'w') { |f| f.write zlib_content }


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

Re: co-authoring commits

[Tuncer Ayaz]

On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:
> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> >
> > By allowing multiple authors, you don't have to decide who's the
> > primary author, as in such situations usually there is no primary
> > at all. I sometimes deliberately override the author when
> > committing and add myself just as another co-author in the commit
> > message, but as others have noted it would be really great if we
> > can just specify multiple authors.
>
> Just recently, there a major thread on the IETF mailing list where
> IETF working group had drafts where people were listed as co-authors
> without their permission, and were upset that the fact that their
> name was added made it seem as if they agreed with the end product.
> (i.e., that they were endorsing the I-D). So while adding formal
> coauthor might solves (a few) problems, it can also introduce
> others.

You can misuse signed-off/reviewed-by/etc the same way.

> Ultimately there is one person who can decide which parts of the
> changes to put in the commit that gets sent to the maintainer. So
> there *is* someone who is the primary author; the person who takes
> the final pass on the patch and then hits the send key.

If you (do it in isolation and) want to take full responsibility, yes,
but I consider reviewed-by/signed-off as taking partial responsibility
because it's a vetting process.

> One could imagine some frankly, quite rare example where there is a
> team of people who votes on each commit before it gets sent out and
> where everyone is equal and there is no hierarchy. In that case,
> perhaps you could set the from field to a mailing list address. But
> honestly, how often is that *all* of the authors are completely
> equal[1]?

For that case something like patchwork, phabricator, or gerrit seems
to be the logical tool to use, and should ideally leave a trace of
approvals and such in the resulting commit message(s). If the patch
management tool takes care of merging the commit(s), it can be harder
to misattribute signed-off/reviewed-by/etc, which is a good thing.

> In my personal practice, if I make significant changes to a patch, I
> will indeed simply change the submitter, and then give credit the
> original author. This is the case where I'm essentially saying, "Bob
> did a lot of work, but I made a bunch of changes, so if things break
> horribly, blame *me*, not Bob".
>
> Alternatively, if I just need to make a few cosmetic changes to
> Alice's patch (i.e., fix white spaces, correct spelling, change the
> commit description so it's validly parsable and understandable
> English, etc.), I'll just add a comment in square brackets
> indicating what changes I made before I committed the change. This
> seems to work just fine, and I don't think we should try to fix
> something that isn't broken.

Perfectly valid use cases, but different from the scenarios Josh
mentioned.

You could of course use multiple (everybody makes their own) commits,
where you risk breaking bisectability and avoid the need for equal
co-authorship support. In pair programming such intermediate commits
will quite often be fixups, and when you attempt to squash the fixups
for bisectability's sake, you may get a desire for co-authorship of
the resulting commit.

Re: co-authoring commits

[Jakub Narębski]

On 2015-06-18 at 23:25, Tuncer Ayaz wrote:
> On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:
>> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
[...]
>> One could imagine some frankly, quite rare example where there is a
>> team of people who votes on each commit before it gets sent out and
>> where everyone is equal and there is no hierarchy. In that case,
>> perhaps you could set the from field to a mailing list address. But
>> honestly, how often is that *all* of the authors are completely
>> equal[1]?
> 
> For that case something like patchwork, phabricator, or gerrit seems
> to be the logical tool to use, and should ideally leave a trace of
> approvals and such in the resulting commit message(s). If the patch
> management tool takes care of merging the commit(s), it can be harder
> to misattribute signed-off/reviewed-by/etc, which is a good thing.

Doesn't Gerrit (at least) use trailer-like structured *notes* in the
'reviews' category (i.e. refs/notes/reviews ref) to store information
about review process?

> You could of course use multiple (everybody makes their own) commits,
> where you risk breaking bisectability and avoid the need for equal
> co-authorship support. In pair programming such intermediate commits
> will quite often be fixups, and when you attempt to squash the fixups
> for bisectability's sake, you may get a desire for co-authorship of
> the resulting commit.

Hmmm... I didn't think about the problem of attributing authorship
for squashed commits.  Though here multiple 'author' headers, or
multiline 'author' header would be a better match than 'coauthor'
header (which itself doesn't need, I think, the date filed, or does it?)

[This is sent from Thunderbird news, so it should be all right]
-- 
Jakub Narębski

Re: co-authoring commits

[Tuncer Ayaz]

On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski <jnareb@gmail.com> wrote:
> On 2015-06-18 at 23:25, Tuncer Ayaz wrote:
> > On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:
> > > On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> [...]
> > > One could imagine some frankly, quite rare example where there
> > > is a team of people who votes on each commit before it gets sent
> > > out and where everyone is equal and there is no hierarchy. In
> > > that case, perhaps you could set the from field to a mailing
> > > list address. But honestly, how often is that *all* of the
> > > authors are completely equal[1]?
> >
> > For that case something like patchwork, phabricator, or gerrit
> > seems to be the logical tool to use, and should ideally leave a
> > trace of approvals and such in the resulting commit message(s). If
> > the patch management tool takes care of merging the commit(s), it
> > can be harder to misattribute signed-off/reviewed-by/etc, which is
> > a good thing.
>
> Doesn't Gerrit (at least) use trailer-like structured *notes* in the
> 'reviews' category (i.e. refs/notes/reviews ref) to store
> information about review process?

Don't remember if it does specifically, but I'm sure it can be
configured to. I know Phabricator appends a lot upon doing the
commit. I'll have to check it the next time I happen to use
Gerrit.

> > You could of course use multiple (everybody makes their own)
> > commits, where you risk breaking bisectability and avoid the need
> > for equal co-authorship support. In pair programming such
> > intermediate commits will quite often be fixups, and when you
> > attempt to squash the fixups for bisectability's sake, you may get
> > a desire for co-authorship of the resulting commit.
>
> Hmmm... I didn't think about the problem of attributing authorship
> for squashed commits. Though here multiple 'author' headers, or

Strictly speaking, in a live pair programming session usually the one
currently typing will be corrected by the other dev, and the roles
will switch when the typist changes.

> multiline 'author' header would be a better match than 'coauthor'
> header (which itself doesn't need, I think, the date filed, or does
> it?)

What makes sense to me is that the date is decoupled from the list of
authors and there is one date only. I think of it as an expanded
version of the previously single-entry author field, where the limit
has been lifted. With my purely git-user hat on, that is.

So, yes, a multiline author header sounds like a solution to me. Maybe
it should be sorted alphabetically upon commit regardless of the order
of --author ONE --author TWO.

> [This is sent from Thunderbird news, so it should be all right]

This is fine, the other one was broken. Out of curiosity what's the
difference between Thunderbird email and news?

Re: co-authoring commits

[Jakub Narębski]

On Fri, Jun 19, 2015 at 11:11 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski <jnareb@gmail.com> wrote:

>> [This is sent from Thunderbird news, so it should be all right]
>
> This is fine, the other one was broken. Out of curiosity what's the
> difference between Thunderbird email and news?

One was sent as Reply All from the news interface (nntp://news.gmane.org),
one was sent as Reply All from the email interface (Gmail account).

Damned if I know why the difference...
-- 
Jakub Narebski