Sublime Forum

Stash went bad, did I loose all my uncommited changes?

#1

I was going through some 30 files to commit their changes, sorting them into clear commits instead of just pushing everything into one big commit.

After doing some of the commits, I came upon one change that I wanted to merge with a previous commit.

So I made a new commit, and stashed all the rest so that I could do some reorganising. Moved the commit down the tree and then squashed the two commits.

But when I popped the stash, to my surprise I noticed Abort and Continue Rebase buttons. I am not thoroughly familiar with Git, so it often happens I am surprised by its peculiarities. I thought just pressing Continue would be the safest choice and that happened without any errors.

But then I noticed none of the stashed files had been restored, and the stash was gone. All files were in their last committed state. Luckily I still had the most important files open in Visual Studio, which warned me of the external file change, and allowed me to rescue the code in at least those files.

Are all my other edits really gone? I canā€™t believe it, because I have come to know Git as quite stable with many ways to restore files, but I have found no way to recover my stashed filesā€¦

If it helps, here is the list of undo steps that Sublime Merge lists in the Repository menu (up to before I started adding my commits). Though going through them did not restore my lost files.

  1. rebase
  2. reset
  3. amend
  4. amend
  5. rebase -i (finish)
  6. rebase -i (start)
  7. reset
  8. commit
  9. commit
  10. commit
  11. commit
  12. reset
  13. reset
  14. commit (ammend)
  15. commit (ammend)
  16. commit
0 Likes
#2

I was finally able to retrieve my lost changes using the instructions provided here: https://stackoverflow.com/questions/89332/how-to-recover-a-dropped-stash-in-git

Until this bug is fixed in Sublime Merge, I would say avoid using Stash!

0 Likes
#3

I do things like that frequently but never lost anything. But even if it would, Iā€™d try Main Menu > Repository > Undo which restores all git commands in reverse order. Guess, this would have simply restored the stash in your case.

Note: You can just select two commits and squash them.

1 Like
#4

Hi Deathaxe, thanks for your reply!

The undo command in the Repository menu is one of the first things I tried (I did mention this, but maybe not so clear). I tried both back-tracking my steps and re-doing them again, but it did not see my files re-appear.

Two commits directly after another can be easily squashed yes, but in my case there were some other commits in between. And to be able to move commits, you need to have no uncommitted files.

0 Likes
#5

Iā€™m pretty sure the undo command only applies to operations on HEAD. Since stash is done separately from HEAD, no undo operation would have been added & thus the undo stack didnā€™t work.

0 Likes
#6

Which squash option have you been using? I frequently use Squash Selected Commits, ignoring new messages (fixup) to handle the original fixup command in git rebase -i. This option (& maybe Squash Selected Commits?) does not require the two commits to be parent/child.

The Abort & Continue Rebase buttons should have been present prior to any stash operations since stash is not a rebase-based operation. You likely had a merge conflict when trying to squash the two commits together (be it applying the squashed commit, or applying one of the latter commits back onto the combined commit). However, Iā€™m not quite sure yet as to why those changes were lost, but Iā€™m going to try to cause this behavior again & see if I can reproduce

I highly recommend making sure the state of your repository & branch are correct before continuing your tasks. Even on the command line, I frequently run git status myself after almost every single command just to make sure everything is in the correct state.

Here are a couple alternatives you can use:

  • Apply the stash, not pop it.
    • this will allow the stash to stay & not get dropped/deleted, giving you the chance to verify success of the stash operation
    • downfall: no native command for git stash apply exists, do you have to use the right click menu in the location bar on the wanted stash
  • Commit on the branch anyways.
    • this is a bit more specific to what youā€™re trying to accomplish here, but can be used in most situations:
      1. stage all files & commit them (the ā€˜all-filesā€™ commit)
      2. do whatever rebase-based operations (the Edit Commit > menu)
      3. right click the commit before the ā€˜all-filesā€™ commit
      4. choose Reset "branch" to this commit > Mixed (default) ...
    • benefit: these operations exist on HEAD allowing the undo stack to come into play

Personally, I donā€™t really recommend using stash outside of super-temporary stashing and even then: apply donā€™t pop (see above). Stashes are a fairly inflexible and lack many useful git behaviors & integrations because of that inflexibility. I ran across this link below a few years back and it pushed me to use actual commits & branches instead:

Git rebase

Given that one of Sublime Mergeā€™s selling points is using ā€˜Real Gitā€™ and the same terminology as Git, I think it would be rather wise to learn and experiment a bit with git rebase [-i] on the command line if you wanted to use the Edit Commit > options. Here is what I skimmed and thought touched on all the right points to explain basics of git rebase -i:

Also, one of the most useful (imho) videos & explanation of git in general is below. I highly recommend watching the entire video, but if not the rebase section starts around 1:28:55. And the reason why you were able to recover the stash data starts around 1:23:37.

3 Likes
#7

I had not noticed the ā€œSquash Selected Commitsā€ option yet. Thanks, I will give that a try!

I should have been able to recognise a merge conflict, I get a lot of those when re-ordering commits, but it didnā€™t seem like that to me at the time. However, you are probably right.

Thanks, I think I will be using the second alternative in the future.

I actually came across the same post when researching my problem. Itā€™s a good article!

I am at the point where I understand the theory, but still sometimes get surprise by the actual outcome. I guess what I am really missing is the practice :slight_smile:

Thanks for all the help!

1 Like