Once you know the hash of the stash commit you dropped, you can apply it as a stash:
git stash apply $stash_hash
Or, you can create a separate branch for it with
git branch recovered $stash_hash
After that, you can do whatever you want with all the normal tools. When you’re done, just blow the branch away.
Finding the hash
If you have only just popped it and the terminal is still open, you will still have the hash value printed by git stash pop
on screen (thanks, Dolda).
Otherwise, you can find it using this for Linux, Unix or Git Bash for Windows:
git fsck --no-reflog | awk '/dangling commit/ {print $3}'
...or using Powershell for Windows:
git fsck --no-reflog | select-string 'dangling commit' | foreach { $_.ToString().Split(" ")[2] }
This will show you all the commits at the tips of your commit graph which are no longer referenced from any branch or tag – every lost commit, including every stash commit you’ve ever created, will be somewhere in that graph.
The easiest way to find the stash commit you want is probably to pass that list to gitk
:
gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )
...or see the answer from emragins if using Powershell for Windows.
This will launch a repository browser showing you every single commit in the repository ever, regardless of whether it is reachable or not.
You can replace gitk
there with something like git log --graph --oneline --decorate
if you prefer a nice graph on the console over a separate GUI app.
To spot stash commits, look for commit messages of this form:
WIP on somebranch: commithash Some old commit message
Note: The commit message will only be in this form (starting with "WIP on") if you did not supply a message when you did git stash
.
The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...
git reflog
and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard
option).
Suppose the old commit was HEAD@{2}
in the ref log:
git reset --hard HEAD@{2}
In Windows, you may need to quote the reference:
git reset --hard "HEAD@{2}"
You can check the history of the candidate old head by just doing a git log HEAD@{2}
(Windows: git log "HEAD@{2}"
).
If you've not disabled per branch reflogs you should be able to simply do git reflog branchname@{1}
as a rebase detaches the branch head before reattaching to the final head. I would double check this, though as I haven't verified this recently.
Per default, all reflogs are activated for non-bare repositories:
[core]
logAllRefUpdates = true
Best Answer
First, let’s clarify what HEAD is and what it means when it is detached.
HEAD is the symbolic name for the currently checked out commit. When HEAD is not detached (the “normal”1 situation: you have a branch checked out), HEAD actually points to a branch’s “ref” and the branch points to the commit. HEAD is thus “attached” to a branch. When you make a new commit, the branch that HEAD points to is updated to point to the new commit. HEAD follows automatically since it just points to the branch.
git symbolic-ref HEAD
yieldsrefs/heads/master
The branch named “master” is checked out.
git rev-parse refs/heads/master
yield17a02998078923f2d62811326d130de991d1a95a
That commit is the current tip or “head” of the master branch.
git rev-parse HEAD
also yields17a02998078923f2d62811326d130de991d1a95a
This is what it means to be a “symbolic ref”. It points to an object through some other reference.
(Symbolic refs were originally implemented as symbolic links, but later changed to plain files with extra interpretation so that they could be used on platforms that do not have symlinks.)
We have
HEAD
→refs/heads/master
→17a02998078923f2d62811326d130de991d1a95a
When HEAD is detached, it points directly to a commit—instead of indirectly pointing to one through a branch. You can think of a detached HEAD as being on an unnamed branch.
git symbolic-ref HEAD
fails withfatal: ref HEAD is not a symbolic ref
git rev-parse HEAD
yields17a02998078923f2d62811326d130de991d1a95a
Since it is not a symbolic ref, it must point directly to the commit itself.
We have
HEAD
→17a02998078923f2d62811326d130de991d1a95a
The important thing to remember with a detached HEAD is that if the commit it points to is otherwise unreferenced (no other ref can reach it), then it will become “dangling” when you checkout some other commit. Eventually, such dangling commits will be pruned through the garbage collection process (by default, they are kept for at least 2 weeks and may be kept longer by being referenced by HEAD’s reflog).
1 It is perfectly fine to do “normal” work with a detached HEAD, you just have to keep track of what you are doing to avoid having to fish dropped history out of the reflog.
The intermediate steps of an interactive rebase are done with a detached HEAD (partially to avoid polluting the active branch’s reflog). If you finish the full rebase operation, it will update your original branch with the cumulative result of the rebase operation and reattach HEAD to the original branch. My guess is that you never fully completed the rebase process; this will leave you with a detached HEAD pointing to the commit that was most recently processed by the rebase operation.
To recover from your situation, you should create a branch that points to the commit currently pointed to by your detached HEAD:
(these two commands can be abbreviated as
git checkout -b temp
)This will reattach your HEAD to the new
temp
branch.Next, you should compare the current commit (and its history) with the normal branch on which you expected to be working:
(You will probably want to experiment with the log options: add
-p
, leave off--pretty=…
to see the whole log message, etc.)If your new
temp
branch looks good, you may want to update (e.g.)master
to point to it:(these two commands can be abbreviated as
git checkout -B master temp
)You can then delete the temporary branch:
Finally, you will probably want to push the reestablished history:
You may need to add
--force
to the end of this command to push if the remote branch can not be “fast-forwarded” to the new commit (i.e. you dropped, or rewrote some existing commit, or otherwise rewrote some bit of history).If you were in the middle of a rebase operation you should probably clean it up. You can check whether a rebase was in process by looking for the directory
.git/rebase-merge/
. You can manually clean up the in-progress rebase by just deleting that directory (e.g. if you no longer remember the purpose and context of the active rebase operation). Usually you would usegit rebase --abort
, but that does some extra resetting that you probably want to avoid (it moves HEAD back to the original branch and resets it back to the original commit, which will undo some of the work we did above).