From: Cornelius Schumacher <schumacher@kde.org>
To: git <git@vger.kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Christian Couder <christian.couder@gmail.com>,
Josh Triplett <josh@joshtriplett.org>
Subject: Re: [RFC] Proof of concept: Support multiple authors
Date: Tue, 31 Jan 2017 01:54:53 +0100 [thread overview]
Message-ID: <3204990.cGxpkETTLk@linux-7ekr> (raw)
In-Reply-To: <xmqqinowuvd7.fsf@gitster.mtv.corp.google.com>
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>
prev parent reply other threads:[~2017-01-31 1:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-29 18:06 [RFC] Proof of concept: Support multiple authors Cornelius Schumacher
2017-01-30 17:56 ` Christian Couder
2017-01-30 19:33 ` Cornelius Schumacher
2017-01-30 20:48 ` Junio C Hamano
2017-01-31 0:54 ` Cornelius Schumacher [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3204990.cGxpkETTLk@linux-7ekr \
--to=schumacher@kde.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=josh@joshtriplett.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.