Jim Jeffries
Jim Jeffries

Reputation: 10081

Get version of a file from before git pull

I'm, not sure if this is possible, but I would like to knwo what version of a file I had before I did a git pull.

For example

  1. I had a set of files which had been deployed to production by git pulling them from github, which weren't behaving as I expected.
  2. I added some logging from my local machine and committed this to github.
  3. I did a git pull to get the new logging
  4. My code inexplicably worked, which makes me think the deployed version had not been updated to the latest version before my pull.

I want to check which version was deployed before I did the git pull in step 3. Is there anyway of doing this?

Upvotes: 0

Views: 1291

Answers (1)

torek
torek

Reputation: 488203

As always, we start with this: git pull is basically git fetch followed by git merge (or, if you've configured it or run it differently, git fetch followed by git rebase).

The git fetch command updates only "remote branch" labels, not local ones, so we get to ignore that part, and thus ask: "after a git merge, how can I tell which revision a branch-label used to name, or which revision HEAD named before?" The answer—well, one of several, but let's use this one—is: "it's in your reflogs".

Git keeps a "ref log" for branch-names, and also a ref-log for HEAD itself. When git merge succeeds and updates both a branch-name and HEAD, the corresponding reflogs are updated with the old-and-new commit IDs as needed.

If you've done some other git checkouts and so on, HEAD's reflog may have been updated more since then. The branch's, however, is only updated when the branch label itself is updated, so it's very likely that the first step backwards in history will tell you where the branch was before the successful merge updated it.

You don't say what the name of your branch is here, so I'll just call it sasquatch. The place sasquatch pointed one step ago is simply sasquatch@{1}.

You can see the raw commit-ID with:

git rev-parse sasquatch@{1}

for instance, or supply that name to git log or git show.

The second step back is sasquatch@{2}, and so on.

In a few cases, you must use quotes or backslashes to protect the curly brace characters { and } from hungry shells that like to eat them, so you might need to write:

git rev-parse 'sasquatch@{1}'

if the version without the quotes errors-out.

You can see all the reflog entries for branch sasquatch with:

git reflog sasquatch

Without an argument, git reflog shows you all the entries for HEAD.


Just for completeness, let's also note here that git merge leaves ORIG_HEAD pointing to the commit-ID from before the merge. This name is good until something else overwrites it, such as a rebase or another merge. However, the reflog names are good for quite a while (although as you accumulate more changes the numbers increment).


All of this tells you about your local repository. You may also have reflogs for origin/ remote-branches; these will tell you what you (or your git) observed when it contacted origin and got updates. They cannot tell you what was actually in place at various times on a remote, except for those times when your git called up theirs and got updates (snapshots in time, as it were).

Upvotes: 4

Related Questions