[asmdev]

After we merge a pull request with rebase + fast forward merge, there is no merge commit created. This leads to a linear commit history.

Does anyone know anyway to look at the linear commit history alone (not GitHub) and tell where a pull request was merged and who merged it?

[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.

[mikepurvis]

GitLab offers this as a merge option, and I really dislike it for this exact reason. Worse still than not knowing which merge is associated with the commit is that you can't even tell the difference between reviewed commits and those which were simply pushed directly to master.

IMO it's far preferable to have an explicit "merge" commit referencing the PR in question, whether that that is a --no-ff merge or a single linear squashed commit.

[zoul]

I think that’s not possible, by definition. There is no merge commit, ergo no information about the merge. You may or may not consider that a feature.