Re: [PATCH 1/8] git-merge-file --ours, --theirs

Nanako Shiraishi [off-list ref] writes:

Quoting Junio C Hamano [off-list ref]

quoted

Except for parse-optification, this one is more or less a verbatim copy of
my patch, and I think I probably deserve an in-body "From: " line for this
[PATCH 1/8], [PATCH 6/8] and [PATCH 8/8] to take the full authorship of
them.

Could you give an guideline to decide when to take authorship and when to
give it to others?  The above seems somewhat arbitrary to me.

It might seem that way to you, as you do not write much C, but I am
reasonably sure Avery understands after having worked on the series.

Imagine that Avery were an area expert (the subsystem maintainer) on "git
merge" and downwards, and somebody who did not know that "merge" has
already been rewritten in C, nor some parts of the system have been
rewritten to use parse-options, submitted a patch series for review and
Avery is helping to polish it up [*1*].

As the subsystem maintainer, Avery looks at the patches, updates parts of
the code that is based on obsolete infrastructure, adds lacking tests and
documentation as necessary, and forwards the tested result upwards for
inclusion.  How would the messages from Avery to me look?

Patches that were majorly reworked should be attributed to Avery, and
obviously new patches that are added for missing tests should be, too.
For example, changes made to git-merge.sh by the original submitter must
be discarded and redone from scratch to builtin-merge.c, and if you look
at the changes, it would be quite obvious that the original patch wouldn't
have served as anything more than giving the specification.

But the ones with minor updates should retain the original authorship.
It unfortunately is not black-and-white, though.

In any case, where does Avery's credit go?  Is there a point in helping to
polish others' patches?

It is recoded on the Signed-off-by line.  When somebody passes a patch
from somebody else, an S-o-b is added for DCO purposes, but it also leaves
the "patch trail"---these people looked at the patch, spent effort to make
sure it is suitable for inclusion by reviewing, polishing, and enhancing.
A subsystem maintainer, or anybody who helps to polish others
contribution, may not necessarily have his name as the "author" of the
patch, and if the patch forwarding is done via e-mail, his name won't be
on the "committer" line either.  But the contribution is still noted and
appreciated, and the hint to pay attention to is by counting non-author
S-o-b and Tested-by lines in the commit messages.

cf. http://lwn.net/SubscriberLink/363456/50efdecf49af77ba/ check the last
table.


[Footnote]

*1* That somebody happens to be me from 18 months ago, but the important
point here is that the person is not Avery as the subsystem maintainer (in
other words, it is immaterial that it happens to be the same person as the
toplevel maintainer).