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 <andrey_ut...@fastmail.com> >> 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.
