git pull with clean local repo causes merge commit

Question

Update: This turned out to be a bug in the version of SmartGit I'm using (version 3.0.11) - an application which is similar to gitk. The "Pushable Commits" list is modified after doing a "git pull" and some local commits not yet pushed are accidentally removed from this UI list. This caused the confusion described in this post where it appeared the only commit which was not pushed was the "Merge commit".

---

I pushed changes to a remote (on GitHub). Two other devs pushed a few commits after me. I had absolutely no local changes or commits and did a "git pull".

Immediately, after it pulled down the changes, it forced me to do a merge commit (allowing me to type the optional message). I've been using Git for ~2 years and I have yet to encounter this situation where pulling down changes into a clean local repo would force a merge commit. The two times this occurred over the past week, I wasn't sure what to do so I pushed this merge commit immediately both times with no issues (!?).

On our team, we have a mix of some devs who prefer rebasing and others who use git pull. I'm wondering if it's possibly related (even though we've had this setup for over a year and I have not encountered this prior to a week ago). I use git pull.

The image below shows the history.

My original commit pushed is the bottom dot on the purple line. Two other devs pushed after me and upon pulling their changes it created the top "Merge Branch" commit in my local repo (on the same purple line).

Answer 1

After looking at your image for even longer, I realized something obvious. Let’s name the commits A to E from bottom to top to make it easier.

So here’s the thing: Before pulling, your local branch was pointing at A which was the commit you had locally.

When looking at commit D however, you can see that the red line does not end in A but somewhere before (the screenshot is not showing that). So that commit was not based on A and as such you could not fast-forward when pulling. You had to create a merge commit instead.

Now you mentioned that you did push A before, so that’s a bit odd. If you really pushed it and D was published already, your push would have failed, and you had to merge it first. If D was not published already, your push would have went through, but then the author of D would have to merge it before being able to push it.

As you neither of that happened and you had to create a merge later when you pulled, the only reason left would be that you actually never pushed your commit A.

Note that committing does not automatically push a commit. As I said in the comments, unless you push/pull, everything you do is completely local. And only when you do push or pull, commits are actually transferred to or from the remote.

(The other option would be that the dev pushing D did get a conflict but chose to force-push instead, removing your commit from the remote repository. If you are using GitHub, this should be visible from that user’s activity log.)

Answer 2

The big thing to remember with this is that git pull is a combination of two commands. git fetch and git commit Also that your local master branch is not the same branch as the remote master.

Someone pushed changes to the remote branch after you pushed your changes. So when you pulled from the remote. Git updated the HEAD of the remote branch and then merged that into your local branch. Merging causes a commit to happen so you will end up with a merge commit.

If you had reset your branch to the commit that you originally pushed and then did git pull --reabse you would find that commits that the other developers would have added would be in line with your branch and you would not have a merge commit.

Generally these merge commits are benign but occasionally they can cause some trouble.

From your comment, when you pushed your local had one or more commits than your remote. Immediately after you pushed then they were equivalent.