Good day!

I did some of the work in the thread (conditionally old_branch ). Next, I needed to transfer this work to another branch (conditionally new_branch ). Since the work is not finished, I did not commit changes, but took advantage of the nest egg ( stash )

 $ git stash $ git stash branch new_branch

I created a new branch new_branch , into which my changes were transferred. All OK.

Then I returned to the old branch and restored its state to my changes.

 $ git checkout old_branch $ git checkout -- .

Changes were rolled back not only in the old branch, but also in the new one (WTF?).
I understand that unfamiliar changes are lost forever, but is there a way to recover the stash from a new branch?

  • eight
    Magnificent translation for "stash". )) - Nick Volynkin ♦
  • @NickVolynkin Yes, now it seems funny to me too. Half an hour ago there wouldn’t be a sticker on the whole Internet to portray my infinite sadness! - Oleg
  • I offer a sad smile with an infinity sign instead of eyes. Something like this: 8-( - Nick Volynkin ♦
  • Guys, saved Local History in the idea. There are not only for files, but also for folders (Recovered deleted files). Ave guys from JetBrains , Ave! - Oleg
  • Happy for you. Essentially, the question is: you understand that when switching branches, unsaved changes in the workspace remain (and if there are conflicts, you just won't switch branches)? - Nick Volynkin ♦

1 answer 1

I created a new branch new_branch, into which my changes were transferred.

no, they are not “transfered”. a new branch was simply created, a copy of the one in which the “stash” was created, i.e., a new pointer was created to the same commit that was current during the creation of the “nest”, then this new branch was assigned the current, working directory has been applied to the changes stored in the “nest egg” , and the “nest” itself has been deleted.

since you immediately followed the checkout command (with an argument . ), the changes in the working directory were deleted .

it is theoretically possible to recover a remote "nest egg" (before the "garbage collection" is carried out). example:

 $ git fsck --no-reflog Checking object directories: 100% (256/256), done. dangling commit 424c2946da3bfe5cbc719f808c1a006612e5cab7

found “dangling” commit and is a remote “nest egg”. this hash can be manipulated as with a “normal stash”:

 $ git show 424c294 commit 424c2946da3bfe5cbc719f808c1a006612e5cab7 Merge: 3330f58 8a98560 Author: aleksandr barakin <a.barakin@...> Date: Fri Oct 6 12:46:55 2017 +0300 WIP on master: 3330f58 20171006124552 diff --cc file index abf3108,abf3108..e1743f8 --- a/file +++ b/file @@@ -1,1 -1,1 +1,2 @@@ 2017-10-06 12:45 ++2017-10-06 12:46 $ git stash show -p 424c294 diff --git a/file b/file index abf3108..e1743f8 100644 --- a/file +++ b/file @@ -1 +1,2 @@ 2017-10-06 12:45 +2017-10-06 12:46 $ git stash apply 424c29 On branch new Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: file no changes added to commit (use "git add" and/or "git commit -a")
  • one
    Thanks for chewing. On the whole, IDEA itself has already saved me, even allowed me to recover deleted files. However, I still did not understand why the $ git checkout -- . command $ git checkout -- . on the old branch touched something on the new branch. Or $ git checkout -- . Does it work regardless of branches? - Oleg
  • one
    Yes, changes to the working directory (working directory, working copy), like the working directory itself, have nothing to do with the repository in general and the branches in particular. i.e. "exist without regard to". the repository (with branches, tags, commits, trees, and other entities) - separately (usually in the .git directory), working copy (with all changes) - separately. - aleksandr barakin
  • 2
    It became absolutely clear to me why it happened. Live and learn. Thank! - Oleg