git fetch specific revision from remote repository

Question

We have a remote git repo that we normally deploy from using git push on our dev server then git pull on on our live servers to get the latest pushed version of the repo.

But if we have committed and pushed a few revisions (without a git pull on the live servers) how can we do a git pull that is referring to the older commit that we want?

i.e. something like git pull -r 3ef0dedda699f56dc1062b5dcc2c59f7ad93ede4

Answer 1

Once you've pulled the repository you should be able to go:

git checkout 3ef0d...

Answer 2

uploadpack.allowReachableSHA1InWant

Since Git 2.5.0 this configuration variable can be enabled on the server, here the GitHub feature request and the GitHub commit enabling this feature.

Bitbucket Server enabled it since version 5.5+.

Usage:

# Make remote with 4 commits, and local with just one.
mkdir server
cd server
git init
touch 1
git add 1
git commit -m 1
git clone ./ ../local
for i in {2..4}; do
    touch "$i"
    git add "$i"
    git commit -m "$i"
done

# Before last commit.
SHA3="$(git log --format='%H' --skip=1 -n1)"
# Last commit.
SHA4="$(git log --format='%H' -n1)"

# Failing control without feature.
cd ../local
# Does not give an error, but does not fetch either.
git fetch origin "$SHA3"
# Error.
git checkout "$SHA3"

# Enable the feature.
cd ../server
git config uploadpack.allowReachableSHA1InWant true

# Now it works.
cd ../local
git fetch origin "$SHA3"
git checkout "$SHA3"
# Error.
git checkout "$SHA4"

Answer 3

If some process on your live server immediately accesses the just-pulled content (i.e. you cannot work with git checkout 3ef0d after pull), you should consider tagging the version you want to deploy in production and specifically checkout that tag on production, so that pulling does not immediately change your working directory. Otherwise you'd risk somebody pushing just prior to your pull.

Answer 4

Note that a git pull git checkout my-old-commit now leaves you in a DETACHED HEAD state - effectively you're sending future commits in this repository down a new commit path. For a deployment repo this is not a major issue, since the only commits should be ones already committed correctly before being pulled.

However, its sometimes useful to check that the commit markers (head,tags,remotes) look identical to the master repo. To fix this following your checkout: git reset - reattaches the head git fetch - syncs the markers for remotes [this may be git version dependent - admittedly our environment is still on 1.7... so might no longer be required YMMV]