CODEWITHSUNDEEP
gitgit-pull
akantoword
akantoword

Reputation: 3044

Why does pulling sometimes make me create a commit?

I'm working with someone on the same branch.

I'm pulling each time after I've made changes to my working directory before I add or commit or push and only sometimes I get the below message. When does it do this and why?

Please enter a commit message to explain why this merge is necessary, especially if it merges an updated upstream into a topic branch.

Lines starting with '#' will be ignored, and an empty message aborts the commit.

Upvotes: 10

Views: 12414

Answers (5)

everag
everag

Reputation: 7662

Simple answer: git pull is, essentially, a combination of git fetch and then a git merge.

As any merge, if Git finds out fast-forwarding is not possible, a traditional merge is necessary (one more commit with two parents), therefore this process asks for a commit message.

Reference: Git docs for branching and merging

Upvotes: 8

paiego
paiego

Reputation: 3787

One simple rule is: As soon as you commit a change to your local repo, if someone else has pushed his/her commit to the origin since you last pulled, you'll be forced to pull (fetch/merge) which will require a merge message before pushing your own changes.

Upvotes: 0

Ricardo Amores
Ricardo Amores

Reputation: 4687

Well, as usually with git, that behaviour depends on a couple of things, in this case you are seeing that message because you got some conflicts between your colleague code and yours and it tries to make a merge commit, instead of doing a fast-forward merge.

Lets clear up the previous phrase, and for that we must start from the beginning:

When you are pulling, what you really are doing are two operations in one:

  • get the remote data to your local machine (git fetch)
  • "join" the data you just retrieved to your local branch (git merge origin/master)

To "join" the code you have two possible operations: merge or rebase

When doing a merge, git creates a new special commit. It contains two parents, one for your last local commit and another for the last code of the merged branch. That's why you see a bifurcation in the history line when you create a merge, if you use a GUI client or git log --graph No matter how special it is, it is still a commit, and this it requires a message for it. This is the case you are describing.

However there is another operation you can do to bring the remote data to your local machine: rebase. In that case you'll get the remote data, and then your local commits (the ones that are not yet in the remote location) will be applied in the same order on top of the last commit your fetched. In that case you are not really creating a merge commit, so no message is needed, because the history will be kept linear.

Well, here's the trick: git pull can actually do a rebase if the operation can be completed without any conflict. That's called a fast-forward pull.

You can configure git to use whatever default you want (rebase or merge) or supply the parameters when doing the merge:

git pull --ff, pulls the data and tries to rebase. This operation will abort if there are conflicts

git pull --no-ffalways create a merge, even if there are no conflicts

Here's an SO answer on how to configure git to use fast-forward by default

But take into consideration that even if you have ff by default, the pull operation will fallback to a normal merge if there are conflicts. If you want to force the pull to make a rebase you'll need to do

git pull --rebase

But note that doing this won't make the conflicts disappear, you'll need to fix them anyway ;)

Upvotes: 4

Gaurav Agarwal
Gaurav Agarwal

Reputation: 14843

Please use git pull --rebase.

Upvotes: 4

Ryan
Ryan

Reputation: 14649

Git most likely wants you to provide a message for the merge. When the origin has changed from your copy, Git will try and merge it. It wants to provide a commit message, because the act of merging is a commit in of itself.

Upvotes: 0

Related Questions