Home/ Questions/Q 8758255
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T14:29:51+00:00

I have a local repository that pulls from a remote one. Running git pull

  • 0

I have a local repository that pulls from a remote one. Running git pull as well as git fetch; git merge FETCH_HEAD used to perform exactly the same action, as is expected from the description of git pull:

DESCRIPTION

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

Presently, and unexpectedly, running git fetch stopped updating the FETCH_HEAD reference correctly. FETCH_HEAD is now stuck to an old commit. Running git fetch downloads all changes to remote tracked branches, but FETCH_HEAD remains unchanged regardless of the branch in which it is run.

# currently in branchone
> git fetch

# branchone is up to date since...
> git rev-parse branchone
593539e8a98ba5980d4b645db3b0f506bb9b6a2c

# ...its in the same commit as the remote branch
> git rev-parse origin/branchone
593539e8a98ba5980d4b645db3b0f506bb9b6a2c

# however FETCH_HEAD shows something different
> git rev-parse FETCH_HEAD
37301df96597ac037f8e7e846fea6fc7df77bea5

git pull still performs the correct task. However running git fetch; git merge FETCH_HEAD will do something different since FETCH_HEAD points to an incorrect commit.

Is there any setting or issue that could be messing with git fetch behavior?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Running git fetch without any options will fetch all references in the remotes and write them to the .git/FETCH_HEAD file. The contents of the file usualy looks something like this:

    37301df96597ac037f8e7e846fea6fc7df77bea5 branch 'master' of github.com:user/repo
593539e8a98ba5980d4b645db3b0f506bb9b6a2c not-for-merge branch 'branchOne' of github.com:user/repo

    When you have a file like this under the .git directory, you can use it as a reference as long as the first thing in that file is either a 40 character hex number, or a shorter hex number that actualy matches to an existing commit.

    # This file can be used as a reference
> cat .git/MAGIC_HEAD
deadbeefdeadbeefdeadbeefdeadbeefdeadbeef lorem ipsum
the rest does not really matter
refrigerator

# And thus it will be interpreted by many git commands like this
> git rev-parse MAGIC_HEAD
deadbeefdeadbeefdeadbeefdeadbeefdeadbeef

    Knowing this we can see that after running git fetch the reference FETCH_HEAD will resolve to is whatever happens to be in that first line

    # Assuming the already mentioned contents of .git/FETCH_HEAD
> git rev-parse FETCH_HEAD
37301df96597ac037f8e7e846fea6fc7df77bea5

    Seems like the order of the contents of .git/FETCH_HEAD is not guaranteed to contain first the reference for the current branch.

    By trying it in different repositories it seems that in some the first line is always the current branch, and thus git fetch; git merge FETCH_HEAD works as expected. On other repositories however the contents of .git/FETCH_HEAD will be ordered differently and often the first line will be a reference to the remote commit of a different branch, thus making the FETCH_HEAD reference incorrect.

    Why it behaves differently is a mystery to me.

    As a solution, if git fetch remote_name branch_name is used only this specific branch is fetched and only that single line will appear in the contents of .git/FETCH_HEAD, making the FETCH_HEAD reference always correct.

    # Will only fetch branchone
> git fetch origin branchone

# FETCH_HEAD will contain only a single line
> cat .git/FETCH_HEAD
593539e8a98ba5980d4b645db3b0f506bb9b6a2c branch 'branchOne' of github.com:user/repo
    • 0