git pull with clean local repo causes merge commit

debugcn Published at Dev

nogridbag

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.

Merge commit

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

poke

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

Collected from the Internet

Please contact [email protected] to delete if infringement.

edited at2021-06-22

Comments

0 comments

From Dev

Override local files with Git Pull | Discard all local files and directories and git the complete latest code from the repo

From Dev

Related Related

Article