Git fast forward merge: Any chance to find the person to blame?

Question

Suppose there is a feature branch 'my-feature'. While I was developing the feature, somebody merged it from 'my-feature' into 'master'. Because it was a fast-forward merge, no commit was made. Some of the changes made by me weren't ready for master yet, and it broke quite a few tests when it was pushed to master. However, since these changes were obviously made by me, I was blamed, not the guy who did the fast-forward merge (whoever that was).

Is there any chance to find out who merged 'my-feature' into 'master' even though it was a fast-forward merge? How can I prevent this from happening in the future?

git reflog apparently only shows what's happening locally. We're using a gitlab server, but I haven't found a way to inspect the reflog of gitlab's repository. Any ideas?

Clisthenes

This is a great question/problem, and I don't know the answer. However, this is probably one reason why many providers such as GitHub and Bitbucket force every merge request through a review process, which they manage. If this had happened with GitHub or Bitbucket, the culprit would be exposed instantly. – Lawanda

gitlab has this feature, too, but I doubt the team will agree with having to go through merge requests every time. – Clisthenes

GIT: Gödel's Inco{mplete,nsistent} Tracker. – Fricandeau

The only way I can think of to discover who did it would be to examine everyone's local copy of the repository, looking at reflogs, etc. But of course, if the person knew what they were doing, that may not uncover any evidence. As far as preventing it goes, don't push your feature branch to a central repository until it's ready. If your reason for pushing it to the central repo was for a backup, use a secondary personal copy of the repo, not the central one... – Sheasheaf

I agree with @Tim and would strongly suggest blocking direct pushes to master. Did you know any developer in your team can now instantly git push -f your history to smithereens? That being said, I doubt there isn't some ssh access log in which you can at least discover who did something when. – Satiate

gitlab has an update hook that prevents forced pushes to a protected branch by anybody. Our master branch is protected; but developers can still push to master, because we all have gitlab master privileges. – Clisthenes

Answer 1

The only chance I see is to try to find some clues in the gitlab-shell.log

The reflog approach will most probably not work because the reflog is deactivated by default for bare repositories. You can turn it on like specified here.

---

Edit: It will not work for fast-forward merges, which makes sense because a fast-forward merge does not change the commit objects.

You should try using git log --pretty=full.

It will show the Committer (who committed - not you) as well as the Author (who wrote the changes - you)

Bcd

That can't be right. The Author and Committer are the same for each and every entry in the log. Apparently, they only differ if you reapply the patch, but not with normal merges and certainly not with ff-merges. – Clisthenes

@digorydoo: right, the problem here is that because this was a fast forward (which is not a merge in any sense, really: it can't be as there was neither merge work done nor a merge commit created) there's no user name attached to the operation. The place that will have a user name attached to the operation is the log file: the reflog update, if there is a reflog on the server, and/or the ssh or http server log file. – Richela

I ssh'd to the server, but git reflog doesn't list anything. Apparently git reflog doesn't work with bare repositories. – Clisthenes

I tried it locally and committer and author were different. That's why I assumed it should work. EDIT: retried and it is not working. It seems I did something different the first time around – Bcd