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