From: David Howells <dhowells@redhat.com>
To: Frans Klaver <fransklaver@gmail.com>
Cc: dhowells@redhat.com, git@vger.kernel.org, valerie.aurora@gmail.com
Subject: Re: How best to handle multiple-authorship commits in GIT?
Date: Thu, 02 Feb 2012 20:33:31 +0000 [thread overview]
Message-ID: <17890.1328214811@redhat.com> (raw)
In-Reply-To: <CAH6sp9P8ehXoC075dcK9ni5rJBV9iCZmLHTBr-UR+-jbD3c6Ww@mail.gmail.com>
Frans Klaver <fransklaver@gmail.com> wrote:
> I always thought of the author field as being an indication of who is
> ultimately responsible for its implementation (the one in the
> pestering spot).
Define 'ultimate responsibility for an implementation'. I'm further developing
patches that Val has (at least partially) implemented. By Val's admission some
of the patches she further developed beyond what Jan Blunck had implemented.
The chain may extend further. To that end all three of us are authors of some
of the patches.
However, if you meant 'maintenance' rather than 'implementation', then, yes,
that would be me (for the moment at least). But if that's the case, then
shouldn't it be 'Maintainer' and not 'Author'? And, besides, that's what the
MAINTAINERS file is for.
> (1) may seem desirous, but doesn't (2) seem like a cleaner and more
> maintainable solution?
No. I would say that properly supporting multiple authors in the commit object
is the cleaner solution. It's not the *easier* solution, however, and would
require an upgrade to the version of GIT used to parse these commits. That
I'll grant you.
> Gitweb will show the entire log message if people are interested in the
> exact change, right?
But if I say to Gitweb "show me the patches authored by Val" it will *not* turn
up these patches, and in that way will deny Val credit. Yes, you can see that
Val altered that patch if you look at that patch directly - but you have to
know where to go and look, in which case you already know or suspect that Val
is credited with patches in that area.
So to make (2) work, Gitweb needs to search for the additional authoring fields
when asked to credit people with the patches they've worked on.
Similarly gitk and possibly other tools would need to do the same.
*That* would be fine by me, I suppose. I don't think it's the correct way to
do it, but it might be the logical way since this wasn't build in from the
beginning - and the main thing would be to turn up the prior or joint
authorship to author-based searches.
David
prev parent reply other threads:[~2012-02-02 20:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 12:25 How best to handle multiple-authorship commits in GIT? David Howells
2012-02-02 13:41 ` Frans Klaver
2012-02-02 18:00 ` Valerie Aurora
2012-02-02 19:57 ` Jakub Narebski
2012-02-02 18:36 ` David Howells
2012-02-03 2:18 ` Valerie Aurora
2012-02-03 5:11 ` Junio C Hamano
2012-02-03 13:47 ` David Howells
2012-02-03 18:27 ` Junio C Hamano
2012-02-03 19:49 ` Valerie Aurora
2012-02-02 20:33 ` David Howells [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=17890.1328214811@redhat.com \
--to=dhowells@redhat.com \
--cc=fransklaver@gmail.com \
--cc=git@vger.kernel.org \
--cc=valerie.aurora@gmail.com \
/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 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 NNTP newsgroup(s).