[gonewest]

Git tracks the committer and the author separately: you should see the “who merged” preserved as the committer and the “who wrote it” as the author.

If each commit notes the issue number in its comment (“Add indentation and trailing white space check to CI [#123]”) then you can see easily when each merge occurred by issue number.

Additionally in GitHub there are conveniences built from these little conventions. The “#123” is displayed as a hyperlink to the issue, and merging a commit that has “Fix #123” automatically closes the issue.

In cases where a feature is big enough to justify multiple commits for clarity, you can mention “#123” in all but the last commit, and “fix #123” in the final commit. Doing so partitions the linear history.

In fact, if someone else notices and fixes a regression caused by the merge, they can push additional commits later on but mention “#123” in their commit as well for documentary purposes. Seeing downstream commits “out of sequence” but with some earlier issue number is a clue this was probably a regression.

[foo101]

This is true only if the merge operation leads to a new commit or altering of existing commits. But your parent comment was asking this question for merge operation where there is no new commit.

The person who merged the commit appears as the committer name only if the rebase led to a change in the SHA1 hash of the commit.

If the pull request branch is already based on master and up-to-date with master, then "git checkout master; git merge pr" performs a fast-forward merge without altering any commits. The SHA1 hash of the commits in the pull request do not change. The merger's name does not appear anywhere because the merger has not done anything except fast-forwarding master.