Git merges all the time

Question

A programmer in my team has a very strange issue with a particular Git repository.

He is the only user making changes to the repo, yet, everytime he pushes, Git will make a merge commit message rather than the actual commit message!

It's hard to explain so a picture is better suited:

At some point it started doing the 'playMakerTest' thing and it never recovered from doing that. Every single commit he now makes and pushes ends up being a merge. Even after cleanly checking out, rebasing the latest commit, moving everything back to master and getting rid of all other branches.

Anyone got an idea why this is happening? I'm really on the brink of just creating a new repo...

Answer 1

I don't know if you're going to delete this question (as suggested in comments above), but for now I will note one thing:

git push cannot create a merge . ¹

When you use git push , you have your git call up some other git (eg, via ssh), after which the two git repositories have a little conversation to discuss which objects yours has that theirs doesn't, and what objects you'd like them to set some of their references to point-to.

For instance, in your case you (or more precisely your programmer in your team) might call up the server git instance and say "please change branch branch to point to commit 1234567... ". In order for the server to do that, the server has to have commit 1234567... so your git may package up that object with any other needed objects, and ship those over, first.

The server-side git does not do any merging during this process, it simply accepts whatever objects are needed first, then takes requests like "set refs/heads/branch to 1234567... ". Those requests are run through permission-checking ( pre-receive and update hooks), which typically do things like refuse non-fast-forward updates, or when using fancier systems like gitolite, check whether the remote user has permission to create, delete, or update a particular branch. ² If the permissions checks allow it, the server-side git process simply sets the requested references (usually branch-names, sometimes tags; there are also note references and such).

Each of these merges, then, are coming from the user (not server) side, before the git push step. As noted in the comments above this was due to the user repeatedly amending an existing-but-pushed commit , which copies the commit to a new ID. Pushing that new ID will not be a fast-forward operation and will by default be refused; to get it to happen, the user is presumably doing additional merges.

---

¹ Well, not by itself, anyway. Using the hooks mentioned above, it's possible to set up a server such that when it receives a push, it saves any new commit(s), rejects the push itself, and then runs additional separate git commands to create merges using the saved-but-rejected commit(s). That's quite a twisted mode of operation, and not something people would or should generally do. (Also, it's not precisely the push creating the merge here, it's the push triggering some other script, and the other script creating the merge.)

Answer 2

After some testing I have confirmed that "Amend Last Commit" was indeed the issue.

After a commit has already been pushed, amend will still try to correct the latest commit. Upon committing it will notice that the commit it just modified had already been pushed and will throw a merge conflict.

The programmer in question missed all the red flags and just "fixed" the merge conflicts and pushed the changes, as a starting Git user, he just figured it was "supposed to be that way". Until others and I started complaining all his commits are merges and mess up the history integrity.