On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski <jnareb@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in