1

My question is why does the answer by @Rich in this SO post work?

I am running git version git version 1.7.1 and have a bare git repository, and keep a development and production environment updated by committing and pushing development changes to the remote ics_client.git and then git pull-ing those changes down to the production system.

After pulling the changes down to the production environment, I see output like the following (in the following example, I tried git fetch followed by git merge FETCH_HEAD, but got the same message as with a git pull.

[ics@bucky ics_client]$ git fetch origin master
gituser@h2oamr's password: 
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 7 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (7/7), done.
From h2oamr:ics_client
 * branch            master     -> FETCH_HEAD
[ics@bucky ics_client]$ git merge FETCH_HEAD
Updating 59a2f6a..05f8d8b
Fast-forward
 Reports.mf     |    5 +-
 fgiusr.c       |  354 ++++++++++++++++++++++++++++----------------------------
 rangebatch.4gl |   52 +++++++-
 3 files changed, 225 insertions(+), 186 deletions(-)
[ics@bucky ics_client]$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
nothing to commit (working directory clean)

So, is this a normal part of git? Am I doing something wrong?

Community
  • 1
  • 1
octopusgrabbus
  • 10,555
  • 15
  • 68
  • 131

1 Answers1

1

The git fetch followed by git merge is performing closely the same operations as a git pull. However, the merge operation is also producing changes of its own (thus your local representation of remote is now ahead) which the following fetch operation handles by syncing your local representation of the remote branch.

In git versions below 1.8.4, when you git pull, FETCH_HEAD is updated and merged into your checked out HEAD but the local representation for the remote repository won't will be updated. So while it says you're ahead of of the remote branch, they're actually in line which each other.

ethesx
  • 1,339
  • 5
  • 19
  • 35
  • Note that OP’s “merge” was a fast-forward merge, so no merge commit was created. – poke Jul 16 '15 at 16:55
  • I added git version to OP, and my version explains what's going on based on your answer. – octopusgrabbus Jul 16 '15 at 17:02
  • @poke Danke - I've removed the misleading information – ethesx Jul 16 '15 at 17:54
  • @poke So, how do I avoid a fast forward merge? – octopusgrabbus Jul 16 '15 at 19:32
  • @octopusgrabbus [Fast-foward merging](http://stackoverflow.com/questions/2850369/why-does-git-fast-forward-merges-by-default/2850413#2850413) is usually helpful, and it’s definitely not a bad thing or the cause of what you described in your question. – poke Jul 16 '15 at 19:44
  • @octopusgrabbus You can have the merge save the merge commit by using the `-no-ff` option, though I agree with poke. Depending on your application you may want to have a commit showing that a merge was done. Say you're merging a forked branch, having that reference can be helpful later. If you're working with a small team, it might not be as beneficial and just clutter your history. – ethesx Jul 16 '15 at 20:43
  • @ethesx tnx for your comment. – octopusgrabbus Jul 16 '15 at 20:57