5

I recently re-installed windows. Now, when executing git stash on any of my github repositories, an error message is returned:

$ git stash
Cannot save the current worktree state

That's everything I get. Trying git -v stash was of no help as stash doesn't seem to have a verbose mode. There are no other changes stashed, and there's only one modified file:

$git stash list
$git status
On branch master
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:   storage.h

no changes added to commit (use "git add" and/or "git commit -a")

I made sure to set user.name and user.email in my global config to the same values they had before and confirmed this using git log, git config user.name and git config user.email.

What can I do to alleviate this?

iFreilicht
  • 13,271
  • 9
  • 43
  • 74
  • 2
    Since `git stash` is actually a script, you could try running it with the script debug flag (`-x`) and observe the low-level "plumbing commands" that get run. One of these is failing unexpectedly. Finding which one, and figuring out why, might be informative. – torek Aug 18 '17 at 20:28
  • @torek Good idea! How can I do this on windows? Trying to run `bash -x git stash` will start the WSL installation. – iFreilicht Aug 18 '17 at 20:32
  • 2
    Although it's possible to run `bash -x ` it's probably easier just to edit the script in place to add `-x` or `set -x` (in case the `git` front end sets up some things, which, well, it does :-) ). The location of the script is given by `git --exec-path`; the script is in that directory, named `git-stash`. – torek Aug 18 '17 at 20:35
  • @torek ok, I managed to make that work, pastebin is [here](https://pastebin.com/a8bn50yF). The one thing I do notice is that `exit 1` is called before `rm -f [...]` is called, so the `.git` folder fills up with files. – iFreilicht Aug 18 '17 at 20:54
  • 1
    OK, so, based on the output, it looks like `rm -f` is exiting with a failure status, even though it obviously succeeded; or bash itself is screwing up somehow with the nested `$( ( ... ) )` construct around line 140 or so of the script (where it writes out the work-tree in non-patch-mode). In particular the work-tree *did* get written; the hash ID shows up in the assignment to variable `w_tree`. (I'm not really sure what to try next, though it's clearly either the exit from `rm` or something to do with the sub-shell nesting.) – torek Aug 18 '17 at 21:23
  • Try again, in a session with a simplified PATH: https://stackoverflow.com/a/44878018/6309 – VonC Aug 18 '17 at 22:54
  • My workaround now is to just install git in bash and use that. – iFreilicht Dec 10 '17 at 00:10

1 Answers1

1

I was getting into this problem today. I was using Windows 10 64bit OS and my Git was 64bit. You might be also seeing sh.exe.stackdump file is created in the current working directory.

The solution that worked for me:

I had to uninstall 64bit Git and installed 32bit Git from https://git-scm.com/download/win.

Matheus Lacerda
  • 5,983
  • 11
  • 29
  • 45
Jijo John
  • 1,368
  • 2
  • 17
  • 31