* Re: [RFC] Proof of concept: Support multiple authors
2017-01-30 20:48 7% ` Junio C Hamano
@ 2017-01-31 0:54 0% ` Cornelius Schumacher
0 siblings, 0 replies; 2+ results
From: Cornelius Schumacher @ 2017-01-31 0:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Josh Triplett
On Monday 30 January 2017 12:48:52 Junio C Hamano wrote:
>
> https://public-inbox.org/git/?q=gmane:83880
> https://public-inbox.org/git/?q=gmane:146223
> https://public-inbox.org/git/?q=gmane:146886
Thanks for putting the links together. That's very useful as a reference.
> The older discussions already cited the cost to update both in-tree
> and out-of-tree tools not to barf when they see such a commit object
> and one of the reason why we would not want to do this, and Ted Ts'o
> gave us another excellent reason why not to do multiple author
> header lines in a commit object header, i.e. "How often is that all
> of the authors are completely equal?"
Just to give a bit of context: In the pair programming environment where I
work we usually use non-personalized workstations and switch the keyboard
between the two people working together quite frequently, sometimes every few
minutes, or even within writing a commit message. There the person pressing
the return button on the commit really does not have a special role. In this
style of working I think it feels like the fairest and most practical
assumption to treat all authors as equal.
> My advice to those who want to record credit to multiple authors is
> to treat the commit author line as recording the primary contact
> when there is a question on the commit and nothing else. Anything
> with richer semantics is better done in the trailer by enriching the
> support of trailer lines with interpret-trailers framework.
Thanks for the advice. I think I will explore this direction a little bit
further and see how handling a situation of multiple authors could be better
done in this framework.
--
Cornelius Schumacher <schumacher@kde.org>
^ permalink raw reply [relevance 0%]
* Re: [RFC] Proof of concept: Support multiple authors
@ 2017-01-30 20:48 7% ` Junio C Hamano
2017-01-31 0:54 0% ` Cornelius Schumacher
0 siblings, 1 reply; 2+ results
From: Junio C Hamano @ 2017-01-30 20:48 UTC (permalink / raw)
To: Christian Couder; +Cc: Cornelius Schumacher, git, Josh Triplett
Christian Couder <christian.couder@gmail.com> writes:
> I am just wondering if you have read and taken into account the
> previous threads on this mailing list about the same subject, like for
> example this one:
>
> https://public-inbox.org/git/CAOvwQ4i_HL7XGnxZrVu3oSnsbnTyxbg8Vh6vzi4c1isSrrexYQ@mail.gmail.com/
Thanks for a starting-point link.
In that discussion, another discussion in the debian BTS is
mentioned,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880
which in turn has links to other, even earlier, discussions, but
they are all gmane links so it would be harder for those who do not
use its NNTP interface (which still works). Here are their modern
counterparts ;-)
https://public-inbox.org/git/?q=gmane:83880
https://public-inbox.org/git/?q=gmane:146223
https://public-inbox.org/git/?q=gmane:146886
The older discussions already cited the cost to update both in-tree
and out-of-tree tools not to barf when they see such a commit object
and one of the reason why we would not want to do this, and Ted Ts'o
gave us another excellent reason why not to do multiple author
header lines in a commit object header, i.e. "How often is that all
of the authors are completely equal?"
Another thing that I didn't see brought up was that it is not enough
to ensure all existing tools are updated not to barf on a commit
with multiple "author" line. You need to define what it means to
have multiple authors and how they are treated by tools in a
consistent way. Think "shortlog", for example. The tool may be
able to be tweaked not to barf, and you may be able to add a random
definition of which of the multiple authors to group a single commit
under (the "random definition" could be "show that same commit
multiple times, once for each author" or it could be "concatenate
the authors to create a single header to list co-authored commits
under, as if they were a single person", or it could be something
equally bogus), but I do not think any single solution satisfies
people's needs, and my gut feeling is that it is not worth to add
tons of options and explain them to the end-users to support these
random things that happen when there are multiple authors.
Incidentally, there recently was a discussion on extending
request-pull by adding a summary of commits by reviewers and
testers.
https://public-inbox.org/git/20170115183051.3565-1-wsa@the-dreams.de/
I would imagine, if it is to be implemented, it would boil down to
teaching shortlog that the "author" line in the commit object header
is not the only thing that matters, and that it should optionally
take notice of lines in the trailer block of the log message (e.g.
perhaps "Co-Authored-by: " trailer suggested by $gmane/146223 above
would help there).
My advice to those who want to record credit to multiple authors is
to treat the commit author line as recording the primary contact
when there is a question on the commit and nothing else. Anything
with richer semantics is better done in the trailer by enriching the
support of trailer lines with interpret-trailers framework.
^ permalink raw reply [relevance 7%]
Results 1-2 of 2 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2017-01-29 18:06 [RFC] Proof of concept: Support multiple authors Cornelius Schumacher
2017-01-30 17:56 ` Christian Couder
2017-01-30 20:48 7% ` Junio C Hamano
2017-01-31 0:54 0% ` Cornelius Schumacher
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).