[gentoo-dev] Re: Please retain authorship of contributed patches

2016-12-01 Thread Michael Palimaka
On 01/12/16 09:33, Sam Jorna wrote:
> On Wed, Nov 30, 2016 at 09:23:56PM +, Andrey Utkin wrote:
>> The difference between my submission and final variant by Matthew is big
>> in number of lines, but is trivial in content as you can see below, so I
>> don't believe that Matthew has written his variant from scratch on his
>> own (he hasn't given any note on tickets on bugs.g.o or github), it
>> seems more like intentional swapping and amending original lines
>> retaining identical outcome.
>>
>> Not that authorship of one or two commits is so crucial for me, or that
>> I'm the most ambitious wannabe-contributor. Hell, there's not much of
>> code at all in the ebuild - it's trivial; but also not much is needed
>> here to give credit. I have contributed to quite some FOSS projects, and
>> have run into theft of my patches a couple of times, and it never was by
>> pure accident.
> 
> Though I wasn't involved in these commits, I have seen how easy and
> accidental it is to lose authorship information on a commit. That being
> said, finding where to draw the line on authorship can be difficult.
> 
> I'm not sure how many others are aware of this, but I'll mention it just
> in case: provided it's done before pushing commits, the commit metadata
> and message can be amended locally with
> 
>   git commit --amend --author="Joe Smith "
> 
> This will update the Author tag but leave the Committer tag untouched
> (and will allow fixing any problems with the commit message itself).
> Amending commits that are not the tip of your local clone will probably
> need an interactive rebase though (but I could be wrong about that).
> 

I've added a new section on the wiki page about this:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Retaining_commit_author_information

Improvements welcome.




[gentoo-dev] Re: Please retain authorship of contributed patches

2016-12-01 Thread Michael Palimaka
On 01/12/16 10:27, Andrew Savchenko wrote:
> On Wed, 30 Nov 2016 17:17:16 -0500 Rich Freeman wrote:
>> On Wed, Nov 30, 2016 at 4:23 PM, Andrey Utkin  
>> wrote:
>>>
>>> I beg affiliated Gentoo developers to stay sane and be thinking not just
>>> about numbers of your commits, but also about community spirit and
>>> relationships. Of course inexperienced contributor gets things not right
>>> first. In such cases, great maintainers fix that and retain original
>>> authorship; good maintainers request for changes and resubmission.
>>>
>>
>> ++
>>
>> I'd have to hunt for where it is written down, but it can't be said
>> enough.  We should definitely be trying to acknowledge the
>> contributions of others whenever possible.  It is really the only
>> recognition a lot of "external" contributors get, and it is the least
>> we can do.  This isn't about copyright or policy or anything like
>> that, but just a nice thing to do, and there is no "threshold" that
>> external contributors need to make.
>>
>> I wouldn't ascribe to malice what is probably just the result of
>> oversight, but it is a good reminder whatever the case may be...
>  
> One more reason to use merge commits for pull requests: original
> author commits with proper authorship will be retained.
> 
> Yes, I know that some people are unhappy with non-linear history,
> but this is how git works, so there is nothing wrong with merge
> commits for user-contributed changes.

Git has distinct 'author' and 'committer' fields for a reason, there's
no reason to not use them. This has nothing to do with merge commits.

In fact, non-merge commits provide a much clearer picture of who did
what. Compare
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6485aff0129ae4c8df5a211af1a51d03ecb6de4
and
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a06f6c599f999a9ae9b1e7ca448712ebfb31ad5f.

The former commit was rebased and clearly shows that Andreas authored
the commit and that I pushed it. The latter was part of a merge commit,
and although it retains authorship information provides no *easy* way to
figure out who the responsible dev is.