2

Every time I think I'm a Git wizard some entirely new and weird thing happens to put me back in my place...

I was in the process of squashing two commits in an interactive rebase, when all of a sudden the outputs from Git started like overwriting themselves, and multiple Git Bash prompts appeared in the mess as if the commands thought they were complete before they actually were (I forgot to take a screenshot unfortunately). My repo now seems corrupt, as I am stuck in REBASE-i mode and cannot abort. Below are some screenshots that will hopefully help the more-Git-wizardry-than-I troubleshoot (git s is an alias for git status). I have literally never seen that Cannot store message before, and I don't understand how it could be generated by rebase. I can always delete the repo and make a fresh clone but I thought I'd appeal to SO before throwing in the towel here...

EDIT:
Here are the steps I took that led up to this issue:

  1. git commit --squash head so that I could squash my latest changes with the previous commit.
  2. git rebase -i --autosquash head^^ to start an interactive rebase with the squash command already set up.
  3. The rebase proceeded normally but then started showing the weird output described above. It started complaining about not being able to unlink .pack files and if I wanted to try again. I'd seen that message before; usually it just keeps asking to retry forever, so instead I exited with Ctrl+C.
  4. At that point, I was unable to git rebase --abort, with the error message shown below.
  5. I tried git rebase --edit-todo and deleted all lines of the todo file, but rebase continued to fail.
  6. Finally I ran git rebase --continue and it got me out of REBASE-i mode, allowing me to get on with my life in a very flustered state...

Version Info:
- Git for Windows: 2.18.0
- Windows: Windows 10 Pro 1803

enter image description here enter image description here

enter image description here

Rabadash8820
  • 2,328
  • 3
  • 27
  • 49

2 Answers2

1

Well, this is clearly a bug and has to do with rebase's --autostash (probably enabled via git config's rebase.autoStash setting). To get more detail and debug you may need to supply your particular Git version.1 What made autostash itself trigger was this:

  1. git commit --squash head so that I could squash my latest changes with the previous commit.
  2. git rebase...

(I assume step 1 is actually git merge --squash HEAD. On Windows, you can write HEAD in all-lowercase, though I believe this is a bad habit since it may suddenly stop working in the future, and does not work on some other systems. If you dislike typing four capital lettters, consider using @ as shorthand for HEAD, which does work everywhere, at least since about Git 1.8.)

Without a git commit in between, git merge --squash leaves everything uncommitted, because --squash always turns on --no-commit. This leaves rebase in the position of being unable to start, except for the ability of git rebase to run git stash (since 1.8.4).

The preceding is wrong, per comments below, and I'm now not at all sure why the autostash code is (must be) running and getting confused.

To do auto-stashing, though, git rebase must in fact run git stash, and there were various bugs (one that I considered serious enough to avoid using autostash) in this until Git version 2.0.1 / 2.1.0, and further bugs fixed much more recently in 2.10 and 2.13.

(I still do not use autostash myself. I'd rather just be reminded that I need to commit or stash before rebasing, and in general, I want to commit at this point.)

The unlink errors are almost certainly Windows-specific and might only be side issues. The, or at least a, problem with emptying out the TODO (git rebase --edit-todo) was supposedly fixed in Git 2.0.1 / 2.1.0! See the release notes.

1This looks to me like a Windows version, which I won't have, although perhaps the bug can be triggered on other systems too. I probably won't have time to dig into it myself anyway, though.

torek
  • 448,244
  • 59
  • 642
  • 775
  • I actually did use `git commit --squash head` (see [docs](https://git-scm.com/docs/git-commit#git-commit---squashltcommitgt)). I didn't realized all-lowercase `head` was a bad habit, that's good to know. I was using Git Bash, not command prompt, if that makes any difference. I also edited my question to include the versions of Git/Windows involved. – Rabadash8820 Aug 23 '18 at 18:27
  • Oh. Well, then `--autostash` / `rebase.autoStash` might not be the culprit. But I think it must still be, or at least still be involved in some way. BTW the concern with `head` (lowercase) is that Git currently stores all this information in flies, but this leads to issues when you, on a Windows box, fetch from Fred on a Linux box and Fred has branches named `polish` (for cleaning up) and `Polish` (for sausages) and, oops, now what. Either Git is going to start forbidding mixed-case ref-names, or these things may get moved to a database where they become case-sensitive. – torek Aug 23 '18 at 18:33
  • Very interesting, things us oblivious Windows users don't even think about :P I like your `@` suggestion, I'll have to start using that. Anyway, if there is some Git mailing list or something where I should submit a bug, I'm happy to do that. – Rabadash8820 Aug 23 '18 at 18:41
  • There are multiple mailing lists I think, some specifically for Windows, one for the main Git project. The Windows guys are pretty active, and Microsoft have built a lot of stuff atop Git and now care about the core technology... – torek Aug 23 '18 at 18:44
0

Well I was able to get out of REBASE mode by running git rebase --continue, so I'm not sure what happened. I'll wait to mark this as the accepted answer in case anybody wants to chime in with a better explanation of what happened.

See @torek's answer/comments for some additional info, though it doesn't technically provide a solution.

Rabadash8820
  • 2,328
  • 3
  • 27
  • 49