Reputation: 10081
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
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
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 checkout
s 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