On 4/26/14, 3:29 AM, Ben Laurie wrote:
I just noticed that if I merge a pull request, then both author and
committer are set to whoever made the pull request.
From the POV of figuring out what went wrong, when things go wrong,
that seems bad.
Is there an easy way to fix that? That is, I would expect it to show
me as the committer and the original author as the author.
This is because git is structured as an immutable DAG. Once a
particular commit (with a specific SHA) is created, its author and
committer (and all other information about it) are fixed for all time,
and can't be changed.
When you merge, a new commit (with you as both author and committer)
will be created for the merge itself, but this won't affect the original
commit. Or, if the merge can be fast-forwarded, then there won't be a
new commit for the merge. (But, as Ted T'so mentions, you can use
--no-ff to always create a merge commit.)
If you want to be shown as the committer on the actual commit itself
(and not a separate merge commit), then you need to cherry-pick (or
rebase) the original commit. cherry-picking creates a *new* commit
(with a different SHA) that has the same contents and same author, but
you as committer.
So, just cherry-pick instead of merge, if you want it to work as you
described. But, the way Ted described (merging with --no-ff) is the
more "typical" git workflow.
--Patrick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
