{"thread":{"id":"39663","subject":"co-authoring commits","startedAt":"2015-06-17T19:52:14Z","lastAt":"2015-06-19T21:25:19Z","messageCount":20,"participants":["Tuncer Ayaz","Junio C Hamano","josh@joshtriplett.org","Theodore Ts'o","Jason Pyeron","Jakub Narębski","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"264072","messageId":"CAOvwQ4i_HL7XGnxZrVu3oSnsbnTyxbg8Vh6vzi4c1isSrrexYQ@mail.gmail.com","threadId":"39663","inReplyTo":null,"subject":"co-authoring commits","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2015-06-17T19:52:14Z","receivedAt":"2015-06-17T19:52:14Z","isPatch":false,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"Even though I don't have time to work on a feature like this, like\nothers before me, I've been in situations where I would have liked to\nset more than one GIT_AUTHOR_NAME (etc.) for a single commit due to\nthe involvement of multiple developers in authoring a change.\n\nIs this something that breaks the design and would never be implemented,\nor can it be integrated such that one can specify co-authors when\ncommitting a change?\n\nI'm thinking:\n\n$ git commit --add-author \"Tony Zwei \"\n"},{"id":"264076","messageId":"xmqq4mm66r99.fsf@gitster.dls.corp.google.com","threadId":"39663","inReplyTo":"CAOvwQ4i_HL7XGnxZrVu3oSnsbnTyxbg8Vh6vzi4c1isSrrexYQ@mail.gmail.com","subject":"Re: co-authoring commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-17T19:58:58Z","receivedAt":"2015-06-17T19:58:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tuncer Ayaz writes:\n\n> Is this something that breaks the design and would never be implemented,\n\nYes.\n"},{"id":"264082","messageId":"CAOvwQ4j2bjR1jnLVyZbw1OCE=xQxbCEFGKcK1bpuv1K3s_Y2EQ@mail.gmail.com","threadId":"39663","inReplyTo":"xmqq4mm66r99.fsf@gitster.dls.corp.google.com","subject":"Re: co-authoring commits","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2015-06-17T20:26:32Z","receivedAt":"2015-06-17T20:26:32Z","isPatch":false,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:\n> Tuncer Ayaz writes:\n>\n> > Is this something that breaks the design and would never be\n> > implemented,\n>\n> Yes.\n\nJunio, thanks for the quick response.\n\nI suppose things have changed since Jonathan Nieder's response in [1]\n(2010), or I've read too much into the mini-thread between Jonathan\nand Josh. I was under the impression that this is generally possible\nwithout shaking up all underpinnings.\n\nFor what it's worth, here's why I would use the feature:\n\nBy allowing multiple authors, you don't have to decide who's the\nprimary author, as in such situations usually there is no primary at\nall. I sometimes deliberately override the author when committing and\nadd myself just as another co-author in the commit message, but as\nothers have noted it would be really great if we can just specify\nmultiple authors.\n\n[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880\n"},{"id":"264084","messageId":"xmqqmvzy59zr.fsf@gitster.dls.corp.google.com","threadId":"39663","inReplyTo":"CAOvwQ4j2bjR1jnLVyZbw1OCE=xQxbCEFGKcK1bpuv1K3s_Y2EQ@mail.gmail.com","subject":"Re: co-authoring commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-17T20:57:12Z","receivedAt":"2015-06-17T20:57:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tuncer Ayaz writes:\n\n> On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:\n>> Tuncer Ayaz writes:\n>>\n>> > Is this something that breaks the design and would never be\n>> > implemented,\n>>\n>> Yes.\n>\n> Junio, thanks for the quick response.\n>\n> I suppose things have changed since Jonathan Nieder's response in [1]\n> (2010),...\n\nI do not think there is anything changed. Jonathan was being a bit\nmore diplomatic and academic than I am.\n\n\"There is no reason in principle some faraway future version of Git\ncould\" is _always_ true as a mental masturbation without taking\nreality into account, aka \"Sounds doable but a lot of trouble\" means\n\"it is doable but it is dubious that it is worth doing\".\n"},{"id":"264085","messageId":"20150617205931.GB24079@cloud","threadId":"39663","inReplyTo":"CAOvwQ4j2bjR1jnLVyZbw1OCE=xQxbCEFGKcK1bpuv1K3s_Y2EQ@mail.gmail.com","subject":"Re: co-authoring commits","fromName":"","fromEmail":"josh@joshtriplett.org","sentAt":"2015-06-17T20:59:31Z","receivedAt":"2015-06-17T20:59:31Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n> On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:\n> > Tuncer Ayaz writes:\n> >\n> > > Is this something that breaks the design and would never be\n> > > implemented,\n> >\n> > Yes.\n> \n> Junio, thanks for the quick response.\n> \n> I suppose things have changed since Jonathan Nieder's response in [1]\n> (2010), or I've read too much into the mini-thread between Jonathan\n> and Josh. I was under the impression that this is generally possible\n> without shaking up all underpinnings.\n> \n> For what it's worth, here's why I would use the feature:\n> \n> By allowing multiple authors, you don't have to decide who's the\n> primary author, as in such situations usually there is no primary at\n> all. I sometimes deliberately override the author when committing and\n> add myself just as another co-author in the commit message, but as\n> others have noted it would be really great if we can just specify\n> multiple authors.\n\nHaving more than one author field in a commit would likely break things,\nbut having a coauthor field seems plausible these days. Git added\nsupport for signed commits, and the world didn't end, so it's possible\nto extend the commit format.\n\n- Josh Triplett\n"},{"id":"264089","messageId":"20150617211749.GA24306@cloud","threadId":"39663","inReplyTo":"xmqqmvzy59zr.fsf@gitster.dls.corp.google.com","subject":"Re: co-authoring commits","fromName":"","fromEmail":"josh@joshtriplett.org","sentAt":"2015-06-17T21:17:49Z","receivedAt":"2015-06-17T21:17:49Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Jun 17, 2015 at 01:57:12PM -0700, Junio C Hamano wrote:\n> Tuncer Ayaz writes:\n> \n> > On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:\n> >> Tuncer Ayaz writes:\n> >>\n> >> > Is this something that breaks the design and would never be\n> >> > implemented,\n> >>\n> >> Yes.\n> >\n> > Junio, thanks for the quick response.\n> >\n> > I suppose things have changed since Jonathan Nieder's response in [1]\n> > (2010),...\n> \n> I do not think there is anything changed. Jonathan was being a bit\n> more diplomatic and academic than I am.\n> \n> \"There is no reason in principle some faraway future version of Git\n> could\" is _always_ true as a mental masturbation without taking\n> reality into account, aka \"Sounds doable but a lot of trouble\" means\n> \"it is doable but it is dubious that it is worth doing\".\n\nWhat happens in old versions of git if you try to look at a signed git\ncommit? The same level of interoperability used there would work here,\nwith the additional property that this would be optional metadata so we\nmight be able to make read-only access work with older versions.\n\n- Josh Triplett\n"},{"id":"264092","messageId":"xmqqegla57hl.fsf@gitster.dls.corp.google.com","threadId":"39663","inReplyTo":"20150617205931.GB24079@cloud","subject":"Re: co-authoring commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-17T21:51:18Z","receivedAt":"2015-06-17T21:51:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"josh@joshtriplett.org writes:\n\n> Having more than one author field in a commit would likely break things,\n> but having a coauthor field seems plausible these days. Git added\n> support for signed commits, and the world didn't end, so it's possible\n> to extend the commit format.\n\nSomething being possible and something being sensible are two\ndifferent things, though.\n\nI agree \"coauthor field that is not understood by anybody\" would\nunlikely break existing implementations, but it is not a useful way\nto add this information to commit objects. For one thing, until you\nteach \"git log\" or its equivalents in everybody's (re)implementation\nof Git, the field will not be shown, you cannot easily edit it while\namending or rebasing, \"git log --grep=\" would not know about it, and\nyou would need \"git cat-file commit\" to view it.\n\nA footer Co-authored-by: does not have any such issue.\n\nWe left commit headers extensible long before we introduced commit\nsigning, and we used it to add the \"encoding\" header. In general,\nwe invent new headers only when structurely necessary. When you\ndeclare that the log message for this indiviaul commit is done in\none encoding, that is not something you would want to _edit_ with\nyour editor while you are editing your message. Similarly you would\nnot want to risk touching the GPG signature of a signed commit or a\nsigned merge while editing your message.\n\nThe _only_ reason I would imagine why somebody may be tempted to\nthink that \"coauthor\" as part of the object header makes sense is\nbecause \"author\" is already there. You can argue that \"author\" did\nnot have to be part of the object header, and that is right. I\nwould agree with you 100% that \"author\" did not have to be there.\n\nBut that is too late to change.\n\nAnd being consistent with a past mistake is not a good reason to\nrepeat that same mistake.\n"},{"id":"264093","messageId":"CAOvwQ4j+62ETPZbikkWeo45a=NgOAnf3uACLQm_D-bbpPoC22A@mail.gmail.com","threadId":"39663","inReplyTo":"xmqqegla57hl.fsf@gitster.dls.corp.google.com","subject":"Re: co-authoring commits","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2015-06-17T22:07:28Z","receivedAt":"2015-06-17T22:07:28Z","isPatch":false,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Wed, Jun 17, 2015 at 11:51 PM, Junio C Hamano wrote:\n> josh@joshtriplett.org writes:\n>\n> > Having more than one author field in a commit would likely break\n> > things, but having a coauthor field seems plausible these days.\n> > Git added support for signed commits, and the world didn't end, so\n> > it's possible to extend the commit format.\n>\n> Something being possible and something being sensible are two\n> different things, though.\n>\n> I agree \"coauthor field that is not understood by anybody\" would\n> unlikely break existing implementations, but it is not a useful way\n> to add this information to commit objects. For one thing, until you\n> teach \"git log\" or its equivalents in everybody's (re)implementation\n> of Git, the field will not be shown, you cannot easily edit it while\n> amending or rebasing, \"git log --grep=\" would not know about it, and\n> you would need \"git cat-file commit\" to view it.\n>\n> A footer Co-authored-by: does not have any such issue.\n>\n> We left commit headers extensible long before we introduced commit\n> signing, and we used it to add the \"encoding\" header. In general, we\n> invent new headers only when structurely necessary. When you declare\n> that the log message for this indiviaul commit is done in one\n> encoding, that is not something you would want to _edit_ with your\n> editor while you are editing your message. Similarly you would not\n> want to risk touching the GPG signature of a signed commit or a\n> signed merge while editing your message.\n>\n> The _only_ reason I would imagine why somebody may be tempted to\n> think that \"coauthor\" as part of the object header makes sense is\n> because \"author\" is already there. You can argue that \"author\" did\n> not have to be part of the object header, and that is right. I would\n> agree with you 100% that \"author\" did not have to be there.\n>\n> But that is too late to change.\n>\n> And being consistent with a past mistake is not a good reason to\n> repeat that same mistake.\n\nMakes sense.\n\nWithout intimate knowledge of current internals,\nwhat about the following potentially crazy plan?\n\n1. demote/deprecate GIT_AUTHOR_*\n\n2. implement a new author-ship model that supports both and treats the\n old entries as supported-but-deprecated\n\n3. maybe auto-migrate entries in the repo, or add a switch to do that\n as part of git-gc or another process\n\n4. extend tooling to support 'commit --add-author' or similar\n\n5. teach git.git tools to properly display additional authors as\n equals in commit ownership\n\n6. let other tools catch up, but rest assured nothing was broken\n\n7. consider other use cases and different implementations\n (flexibility), to not have to repeat this 5 years down the road for\n another field\n"},{"id":"264097","messageId":"20150617222828.GB24438@cloud","threadId":"39663","inReplyTo":"xmqqegla57hl.fsf@gitster.dls.corp.google.com","subject":"Re: co-authoring commits","fromName":"","fromEmail":"josh@joshtriplett.org","sentAt":"2015-06-17T22:28:28Z","receivedAt":"2015-06-17T22:28:28Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Jun 17, 2015 at 02:51:18PM -0700, Junio C Hamano wrote:\n> josh@joshtriplett.org writes:\n> \n> > Having more than one author field in a commit would likely break things,\n> > but having a coauthor field seems plausible these days. Git added\n> > support for signed commits, and the world didn't end, so it's possible\n> > to extend the commit format.\n> \n> Something being possible and something being sensible are two\n> different things, though.\n> \n> I agree \"coauthor field that is not understood by anybody\" would\n> unlikely break existing implementations, but it is not a useful way\n> to add this information to commit objects. For one thing, until you\n> teach \"git log\" or its equivalents in everybody's (re)implementation\n> of Git, the field will not be shown, you cannot easily edit it while\n> amending or rebasing, \"git log --grep=\" would not know about it, and\n> you would need \"git cat-file commit\" to view it.\n> \n> A footer Co-authored-by: does not have any such issue.\n\nSure it does; while it would display in raw form because it's a part of\nthe commit message, you'd still have to teach \"git log --author\" about\nit (git grep is not a substitute), map it through mailmap, teach git\nshortlog about it, teach send-email and format-patch to use it in mail\nheaders, teach repository statistics tools about it, and in general\nteach every tool that reads the \"author\" field of a commit to handle\nco-authors. And if it's a pseudo-field in the commit, you'd also have\nto have more complex parsing rules to find and parse it.\n\nGit has almost no understanding of in-band magic \"headers\" in a commit\nmessage. It has a bit of support for generating (but not parsing)\nSigned-off-by, and send-email has some support for adding *-by headers\nto Cc, but a pseudo-header that git tools actually *parse* out of the\ncommit message would be a first.\n\n> We left commit headers extensible long before we introduced commit\n> signing, and we used it to add the \"encoding\" header. In general,\n> we invent new headers only when structurely necessary. When you\n> declare that the log message for this indiviaul commit is done in\n> one encoding, that is not something you would want to _edit_ with\n> your editor while you are editing your message. Similarly you would\n> not want to risk touching the GPG signature of a signed commit or a\n> signed merge while editing your message.\n> \n> The _only_ reason I would imagine why somebody may be tempted to\n> think that \"coauthor\" as part of the object header makes sense is\n> because \"author\" is already there. You can argue that \"author\" did\n> not have to be part of the object header, and that is right. I\n> would agree with you 100% that \"author\" did not have to be there.\n\nAuthor and committer are used by many git tools; if they weren't part of\nthe object header, they'd need to be part of some pseudo-header with a\nstandardized format that git can parse.\n\n- Josh Triplett\n"},{"id":"264098","messageId":"xmqq381q551o.fsf@gitster.dls.corp.google.com","threadId":"39663","inReplyTo":"20150617222828.GB24438@cloud","subject":"Re: co-authoring commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-17T22:44:03Z","receivedAt":"2015-06-17T22:44:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"josh@joshtriplett.org writes:\n\n> Author and committer are used by many git tools; if they weren't part of\n> the object header, they'd need to be part of some pseudo-header with a\n> standardized format that git can parse.\n\nYes, the same goes to the address on Signed-off-by: footers. There\nrecently was a series to enhance the footer list handling (Christian\nCc'ed) for the generation and maintenance side, and I do think it is\nreasonable to further add enhanced support for footers.\n\nThat does not argue for having a new \"coauthor\" as a new commit\nobject header at all, though.\n"},{"id":"264099","messageId":"20150617225224.GF4076@thunk.org","threadId":"39663","inReplyTo":"CAOvwQ4j2bjR1jnLVyZbw1OCE=xQxbCEFGKcK1bpuv1K3s_Y2EQ@mail.gmail.com","subject":"Re: co-authoring commits","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2015-06-17T22:52:24Z","receivedAt":"2015-06-17T22:52:24Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n> \n> By allowing multiple authors, you don't have to decide who's the\n> primary author, as in such situations usually there is no primary at\n> all. I sometimes deliberately override the author when committing and\n> add myself just as another co-author in the commit message, but as\n> others have noted it would be really great if we can just specify\n> multiple authors.\n\nJust recently, there a major thread on the IETF mailing list where\nIETF working group had drafts where people were listed as co-authors\nwithout their permission, and were upset that the fact that their name\nwas added made it seem as if they agreed with the end product. (i.e.,\nthat they were endorsing the I-D). So while adding formal coauthor\nmight solves (a few) problems, it can also introduce others.\n\nUltimately there is one person who can decide which parts of the\nchanges to put in the commit that gets sent to the maintainer. So\nthere *is* someone who is the primary author; the person who takes the\nfinal pass on the patch and then hits the send key.\n\nOne could imagine some frankly, quite rare example where there is a\nteam of people who votes on each commit before it gets sent out and\nwhere everyone is equal and there is no hierarchy. In that case,\nperhaps you could set the from field to a mailing list address. But\nhonestly, how often is that *all* of the authors are completely\nequal[1]?\n\nIn my personal practice, if I make significant changes to a patch, I\nwill indeed simply change the submitter, and then give credit the\noriginal author. This is the case where I'm essentially saying, \"Bob\ndid a lot of work, but I made a bunch of changes, so if things break\nhorribly, blame *me*, not Bob\".\n\nAlternatively, if I just need to make a few cosmetic changes to\nAlice's patch (i.e., fix white spaces, correct spelling, change the\ncommit description so it's validly parsable and understandable\nEnglish, etc.), I'll just add a comment in square brackets indicating\nwhat changes I made before I committed the change. This seems to work\njust fine, and I don't think we should try to fix something that isn't\nbroken.\n\n\t\t\t\t\t\t- Ted\n\n\n[1] Gilbert and Sullivan attacked this notion is a commedic way in\n\"The Gondoliers\"; especially in the songs \"Replying we sing as one\nindividual\" and \"There Lived a King\":\n\n\t https://www.youtube.com/watch?v=YD0dgXTQ3K0\n\t https://www.youtube.com/watch?v=oSaVdqcDgZc\n"},{"id":"264101","messageId":"20150617230654.GA27206@cloud","threadId":"39663","inReplyTo":"20150617225224.GF4076@thunk.org","subject":"Re: co-authoring commits","fromName":"","fromEmail":"josh@joshtriplett.org","sentAt":"2015-06-17T23:06:54Z","receivedAt":"2015-06-17T23:06:54Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Jun 17, 2015 at 06:52:24PM -0400, Theodore Ts'o wrote:\n> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n> > \n> > By allowing multiple authors, you don't have to decide who's the\n> > primary author, as in such situations usually there is no primary at\n> > all. I sometimes deliberately override the author when committing and\n> > add myself just as another co-author in the commit message, but as\n> > others have noted it would be really great if we can just specify\n> > multiple authors.\n> \n> Just recently, there a major thread on the IETF mailing list where\n> IETF working group had drafts where people were listed as co-authors\n> without their permission, and were upset that the fact that their name\n> was added made it seem as if they agreed with the end product. (i.e.,\n> that they were endorsing the I-D). So while adding formal coauthor\n> might solves (a few) problems, it can also introduce others.\n> \n> Ultimately there is one person who can decide which parts of the\n> changes to put in the commit that gets sent to the maintainer. So\n> there *is* someone who is the primary author; the person who takes the\n> final pass on the patch and then hits the send key.\n\nI've worked on many patches with another person in a shared screen\nsession, co-authoring a series of patches and commit messages in vim,\nand writing an email in mutt. There were, ultimately, two people\ndeciding what to put in a commit and send to the maintainer. This is,\nadmittedly, unusual, but pair programming is not ridiculously uncommon.\n\n> In that case, perhaps you could set the from field to a mailing list\n> address.\n\nThe \"From\" field in email headers supports a list of comma-separated\naddresses, just like To and Cc. Speaking from experience, this\nmore-or-less works with all the mail software we tried it with, with the\noccasional program only displaying the first or last entry.\n\n- Josh Triplett\n"},{"id":"264175","messageId":"FBF98192E9F44B6E97F211B961DC7905@black7","threadId":"39663","inReplyTo":"20150617225224.GF4076@thunk.org","subject":"RE: co-authoring commits","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2015-06-18T10:54:51Z","receivedAt":"2015-06-18T10:54:51Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Theodore Ts'o\n> Sent: Wednesday, June 17, 2015 6:52 PM\n> \n> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n> > \n> > By allowing multiple authors, you don't have to decide who's the \n> > primary author, as in such situations usually there is no \n> primary at \n> > all. I sometimes deliberately override the author when \n> committing and \n> > add myself just as another co-author in the commit message, but as \n> > others have noted it would be really great if we can just specify \n> > multiple authors.\n\n> One could imagine some frankly, quite rare example where \n> there is a team of people who votes on each commit before it \n> gets sent out and where everyone is equal and there is no \n> hierarchy. In that case, perhaps you could set the from \n> field to a mailing list address.\n\nThis is a perfect use the signed commit by multiple persons. Git already\nsupports it (under the hood and in reporting).\n\nA quick google pulled up my notes on this:\n\nhttp://marc.info/?l=git&m=140845378317052&w=2\n\n$ cat merge-multisigs.sh\n#!/bin/bash\n(\n for i in \"$@\"\n do\n gpg --dearmor < \"$i\"\n done\n) | gpg --enarmor\n\n$ cat write-commit.ruby\n#!/usr/bin/irb\nrequire 'fileutils'\nfile = File.open(ARGV[0], \"rb\")\ncontent = file.read\nheader = \"commit #{content.length}\\0\"\nstore = header + content\nrequire 'digest/sha1'\nsha1 = Digest::SHA1.hexdigest(store)\nrequire 'zlib'\nzlib_content = Zlib::Deflate.deflate(store)\npath = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]\nFileUtils.mkdir_p(File.dirname(path))\nFile.open(path, 'w') { |f| f.write zlib_content }\n\n\n--\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n- -\n- Jason Pyeron PD Inc. http://www.pdinc.us -\n- Principal Consultant 10 West 24th Street #100 -\n- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -\n- -\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- \n"},{"id":"264251","messageId":"55833758.6010000@gmail.com","threadId":"39663","inReplyTo":"xmqq381q551o.fsf@gitster.dls.corp.google.com","subject":"Re: co-authoring commits","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2015-06-18T21:25:44Z","receivedAt":"2015-06-18T21:25:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> josh@joshtriplett.org writes:\n>\n>> Author and committer are used by many git tools; if they weren't part of\n>> the object header, they'd need to be part of some pseudo-header with a\n>> standardized format that git can parse.\n>\n> Yes, the same goes to the address on Signed-off-by: footers. There\n> recently was a series to enhance the footer list handling (Christian\n> Cc'ed) for the generation and maintenance side, and I do think it is\n> reasonable to further add enhanced support for footers.\n>\n> That does not argue for having a new \"coauthor\" as a new commit\n> object header at all, though.\n\nThe threshold for modifying commit object is high. This is an\nABI-level change, something to do if there is no other solution.\n\nAuthor and committer include datetime in the contents of the\nfield, which is used by Git for heuristics limiting walk. Coauthor\nwould have the same date as author, isn't it? If, after long\nand involved discussion, we didn't add 'generation' field (for\neasier cutting history walking), what chance adding 'coauthor'\nhas.\n\nOTOH it would be nice to have support for .mailmap, and for\ngrepping... but the former could conceivably be added to the trailer\ntool, the latter can be done with appropriate regexp in\n\"git log --grep=...\".\n\nI wonder what would break if one used 'Name , Name '\nas the author...\n\n-- \nJakub Narębski\n"},{"id":"264252","messageId":"CAOvwQ4jb-w4+Ah3ZhVE0j1aXLx1=8tRN3Wo98tz+G-wEqLGAcA@mail.gmail.com","threadId":"39663","inReplyTo":"20150617225224.GF4076@thunk.org","subject":"Re: co-authoring commits","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2015-06-18T21:25:54Z","receivedAt":"2015-06-18T21:25:54Z","isPatch":false,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:\n> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n> >\n> > By allowing multiple authors, you don't have to decide who's the\n> > primary author, as in such situations usually there is no primary\n> > at all. I sometimes deliberately override the author when\n> > committing and add myself just as another co-author in the commit\n> > message, but as others have noted it would be really great if we\n> > can just specify multiple authors.\n>\n> Just recently, there a major thread on the IETF mailing list where\n> IETF working group had drafts where people were listed as co-authors\n> without their permission, and were upset that the fact that their\n> name was added made it seem as if they agreed with the end product.\n> (i.e., that they were endorsing the I-D). So while adding formal\n> coauthor might solves (a few) problems, it can also introduce\n> others.\n\nYou can misuse signed-off/reviewed-by/etc the same way.\n\n> Ultimately there is one person who can decide which parts of the\n> changes to put in the commit that gets sent to the maintainer. So\n> there *is* someone who is the primary author; the person who takes\n> the final pass on the patch and then hits the send key.\n\nIf you (do it in isolation and) want to take full responsibility, yes,\nbut I consider reviewed-by/signed-off as taking partial responsibility\nbecause it's a vetting process.\n\n> One could imagine some frankly, quite rare example where there is a\n> team of people who votes on each commit before it gets sent out and\n> where everyone is equal and there is no hierarchy. In that case,\n> perhaps you could set the from field to a mailing list address. But\n> honestly, how often is that *all* of the authors are completely\n> equal[1]?\n\nFor that case something like patchwork, phabricator, or gerrit seems\nto be the logical tool to use, and should ideally leave a trace of\napprovals and such in the resulting commit message(s). If the patch\nmanagement tool takes care of merging the commit(s), it can be harder\nto misattribute signed-off/reviewed-by/etc, which is a good thing.\n\n> In my personal practice, if I make significant changes to a patch, I\n> will indeed simply change the submitter, and then give credit the\n> original author. This is the case where I'm essentially saying, \"Bob\n> did a lot of work, but I made a bunch of changes, so if things break\n> horribly, blame *me*, not Bob\".\n>\n> Alternatively, if I just need to make a few cosmetic changes to\n> Alice's patch (i.e., fix white spaces, correct spelling, change the\n> commit description so it's validly parsable and understandable\n> English, etc.), I'll just add a comment in square brackets\n> indicating what changes I made before I committed the change. This\n> seems to work just fine, and I don't think we should try to fix\n> something that isn't broken.\n\nPerfectly valid use cases, but different from the scenarios Josh\nmentioned.\n\nYou could of course use multiple (everybody makes their own) commits,\nwhere you risk breaking bisectability and avoid the need for equal\nco-authorship support. In pair programming such intermediate commits\nwill quite often be fixups, and when you attempt to squash the fixups\nfor bisectability's sake, you may get a desire for co-authorship of\nthe resulting commit.\n"},{"id":"264273","messageId":"20150619042519.GB26001@peff.net","threadId":"39663","inReplyTo":"55833758.6010000@gmail.com","subject":"Re: co-authoring commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-19T04:25:20Z","receivedAt":"2015-06-19T04:25:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:\n\n> Author and committer include datetime in the contents of the\n> field, which is used by Git for heuristics limiting walk. Coauthor\n> would have the same date as author, isn't it? If, after long\n> and involved discussion, we didn't add 'generation' field (for\n> easier cutting history walking), what chance adding 'coauthor'\n> has.\n\nI don't think the two situations are comparable. I would (and did) argue\nthat a \"generation\" field is a bad header to bake in because of what it\nmeans (it is redundant with the graph structure).\n\nWhereas \"co-author\" is not a fundamentally bad; it's just not something\nwe chose to support early on, and it would have to be added now.\n\n> OTOH it would be nice to have support for .mailmap, and for\n> grepping... but the former could conceivably be added to the trailer\n> tool, the latter can be done with appropriate regexp in\n> \"git log --grep=...\".\n\nI don't think we munge trailers during \"git log\" pretty-printing at all\nnow, but it is certainly something we could add (including mailmap-ing\nthem). That doesn't seem like much more work than showing the co-author\nfield, and it's a lot more generally applicable (you could mailmap\nS-O-B, Reviewed-by, and so forth).\n\nSimilarly, something like \"git shortlog\" would have to learn about\nmultiple authors under the \"co-author\" scheme. But likewise, it would\nnot be much more work to teach it something like:\n\n git shortlog --field=Reviewed-by\n\nto handle an arbitrary trailer. And that is much more flexible.\n\n> I wonder what would break if one used 'Name , Name '\n> as the author...\n\nThe \"normal\" parser we use for pretty-printing goes left-to-right and\nwill stop at the first \">\", and show only the first author.\n\nOlder versions of git would then get the date wrong, complaining about\nthe \",\". Newer versions parse the date from right-to-left to work around\nsuch bogosities (especially things like \">\") and so will parse\nback to the second \">\".\n\nFsck will definitely complain about it.\n\n-Peff\n"},{"id":"264348","messageId":"5584593A.5010406@gmail.com","threadId":"39663","inReplyTo":"20150619042519.GB26001@peff.net","subject":"Re: co-authoring commits","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2015-06-19T18:02:34Z","receivedAt":"2015-06-19T18:02:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 2015-06-19 at 06:25, Jeff King wrote:\n> On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:\n>> Author and committer include datetime in the contents of the\n>> field, which is used by Git for heuristics limiting walk. Coauthor\n>> would have the same date as author, isn't it? If, after long\n>> and involved discussion, we didn't add 'generation' field (for\n>> easier cutting history walking), what chance adding 'coauthor'\n>> has.\n> I don't think the two situations are comparable. I would (and did) argue\n> that a \"generation\" field is a bad header to bake in because of what it\n> means (it is redundant with the graph structure).\n>\n> Whereas \"co-author\" is not a fundamentally bad; it's just not something\n> we chose to support early on, and it would have to be added now.\nIt is true that \"generation\" field is redundant with the graph\nstructure, but it is\nnot necessarily something bad. You don't avoid using red-black trees or\nAVL trees\nbecause they keep some _redundant_ \"bookkeeping\" data in the node structure.\nSame for \"generation\" header: it is bookkeeping, but would make Git more\neffective\n(faster).\n\nThough I don't think any distributed version control system store such\ndata in\ntheir equivalent of commit objects... maybe Veracity (I didn't check)...\n>> OTOH it would be nice to have support for .mailmap, and for\n>> grepping... but the former could conceivably be added to the trailer\n>> tool, the latter can be done with appropriate regexp in\n>> \"git log --grep=...\".\n> I don't think we munge trailers during \"git log\" pretty-printing at all\n> now, but it is certainly something we could add (including mailmap-ing\n> them). That doesn't seem like much more work than showing the co-author\n> field, and it's a lot more generally applicable (you could mailmap\n> S-O-B, Reviewed-by, and so forth).\nThis is certainly something nice to have. Though for author and\ncommitter (and also\nfor tagger if I remember it correctly) we have mailmap-aware and\nnot-mailmapped\nversions. There isn't anything like that for trailers.\n>\n> Similarly, something like \"git shortlog\" would have to learn about\n> multiple authors under the \"co-author\" scheme. But likewise, it would\n> not be much more work to teach it something like:\n>\n> git shortlog --field=Reviewed-by\n>\n> to handle an arbitrary trailer. And that is much more flexible.\nIt would also be nice to have something like this for blame... but at\nleast multiple\nauthors support doesn't make much sense wrt display uless using graphical\nblame tool (like \"git gui blame\").\n>\n>> I wonder what would break if one used 'Name , Name '\n>> as the author...\n> The \"normal\" parser we use for pretty-printing goes left-to-right and\n> will stop at the first \">\", and show only the first author.\n>\n> Older versions of git would then get the date wrong, complaining about\n> the \",\". Newer versions parse the date from right-to-left to work around\n> such bogosities (especially things like \">\") and so will parse\n> back to the second \">\".\n>\n> Fsck will definitely complain about it.\nAh, that is a problem.\n\nIf I remember correctly, I have seen somewhere using Bob+Alice for the\nname part\nand or for the email\npart...\nWould this work, I wonder?\n\n[hoping that Thunderbird email didn;t screw up formatting]\n-- \nJakub Narębski\n"},{"id":"264350","messageId":"55845CFE.4070407@gmail.com","threadId":"39663","inReplyTo":"CAOvwQ4jb-w4+Ah3ZhVE0j1aXLx1=8tRN3Wo98tz+G-wEqLGAcA@mail.gmail.com","subject":"Re: co-authoring commits","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2015-06-19T18:18:38Z","receivedAt":"2015-06-19T18:18:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 2015-06-18 at 23:25, Tuncer Ayaz wrote:\n> On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:\n>> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n[...]\n>> One could imagine some frankly, quite rare example where there is a\n>> team of people who votes on each commit before it gets sent out and\n>> where everyone is equal and there is no hierarchy. In that case,\n>> perhaps you could set the from field to a mailing list address. But\n>> honestly, how often is that *all* of the authors are completely\n>> equal[1]?\n> \n> For that case something like patchwork, phabricator, or gerrit seems\n> to be the logical tool to use, and should ideally leave a trace of\n> approvals and such in the resulting commit message(s). If the patch\n> management tool takes care of merging the commit(s), it can be harder\n> to misattribute signed-off/reviewed-by/etc, which is a good thing.\n\nDoesn't Gerrit (at least) use trailer-like structured *notes* in the\n'reviews' category (i.e. refs/notes/reviews ref) to store information\nabout review process?\n\n> You could of course use multiple (everybody makes their own) commits,\n> where you risk breaking bisectability and avoid the need for equal\n> co-authorship support. In pair programming such intermediate commits\n> will quite often be fixups, and when you attempt to squash the fixups\n> for bisectability's sake, you may get a desire for co-authorship of\n> the resulting commit.\n\nHmmm... I didn't think about the problem of attributing authorship\nfor squashed commits. Though here multiple 'author' headers, or\nmultiline 'author' header would be a better match than 'coauthor'\nheader (which itself doesn't need, I think, the date filed, or does it?)\n\n[This is sent from Thunderbird news, so it should be all right]\n-- \nJakub Narębski\n"},{"id":"264385","messageId":"CAOvwQ4gYsQtZPWOA+1gBtdw9XkjQ4WGipk9grb+_ad9iiBj5Og@mail.gmail.com","threadId":"39663","inReplyTo":"55845CFE.4070407@gmail.com","subject":"Re: co-authoring commits","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2015-06-19T21:11:12Z","receivedAt":"2015-06-19T21:11:12Z","isPatch":false,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote:\n> On 2015-06-18 at 23:25, Tuncer Ayaz wrote:\n> > On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:\n> > > On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:\n> [...]\n> > > One could imagine some frankly, quite rare example where there\n> > > is a team of people who votes on each commit before it gets sent\n> > > out and where everyone is equal and there is no hierarchy. In\n> > > that case, perhaps you could set the from field to a mailing\n> > > list address. But honestly, how often is that *all* of the\n> > > authors are completely equal[1]?\n> >\n> > For that case something like patchwork, phabricator, or gerrit\n> > seems to be the logical tool to use, and should ideally leave a\n> > trace of approvals and such in the resulting commit message(s). If\n> > the patch management tool takes care of merging the commit(s), it\n> > can be harder to misattribute signed-off/reviewed-by/etc, which is\n> > a good thing.\n>\n> Doesn't Gerrit (at least) use trailer-like structured *notes* in the\n> 'reviews' category (i.e. refs/notes/reviews ref) to store\n> information about review process?\n\nDon't remember if it does specifically, but I'm sure it can be\nconfigured to. I know Phabricator appends a lot upon doing the\ncommit. I'll have to check it the next time I happen to use\nGerrit.\n\n> > You could of course use multiple (everybody makes their own)\n> > commits, where you risk breaking bisectability and avoid the need\n> > for equal co-authorship support. In pair programming such\n> > intermediate commits will quite often be fixups, and when you\n> > attempt to squash the fixups for bisectability's sake, you may get\n> > a desire for co-authorship of the resulting commit.\n>\n> Hmmm... I didn't think about the problem of attributing authorship\n> for squashed commits. Though here multiple 'author' headers, or\n\nStrictly speaking, in a live pair programming session usually the one\ncurrently typing will be corrected by the other dev, and the roles\nwill switch when the typist changes.\n\n> multiline 'author' header would be a better match than 'coauthor'\n> header (which itself doesn't need, I think, the date filed, or does\n> it?)\n\nWhat makes sense to me is that the date is decoupled from the list of\nauthors and there is one date only. I think of it as an expanded\nversion of the previously single-entry author field, where the limit\nhas been lifted. With my purely git-user hat on, that is.\n\nSo, yes, a multiline author header sounds like a solution to me. Maybe\nit should be sorted alphabetically upon commit regardless of the order\nof --author ONE --author TWO.\n\n> [This is sent from Thunderbird news, so it should be all right]\n\nThis is fine, the other one was broken. Out of curiosity what's the\ndifference between Thunderbird email and news?\n"},{"id":"264386","messageId":"CANQwDwd8V-RO2XbkdraLhwmvCbUb=1KBTxmf-ZtyQ7gCVXAeWQ@mail.gmail.com","threadId":"39663","inReplyTo":"CAOvwQ4gYsQtZPWOA+1gBtdw9XkjQ4WGipk9grb+_ad9iiBj5Og@mail.gmail.com","subject":"Re: co-authoring commits","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2015-06-19T21:25:19Z","receivedAt":"2015-06-19T21:25:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, Jun 19, 2015 at 11:11 PM, Tuncer Ayaz wrote:\n> On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote:\n\n>> [This is sent from Thunderbird news, so it should be all right]\n>\n> This is fine, the other one was broken. Out of curiosity what's the\n> difference between Thunderbird email and news?\n\nOne was sent as Reply All from the news interface (nntp://news.gmane.org),\none was sent as Reply All from the email interface (Gmail account).\n\nDamned if I know why the difference...\n-- \nJakub Narebski\n"}]}