1

I sometimes make periodic "checkpoint" commits if I'm making a lot of changes. When I'm all finished with my big changes, I use git rebase -i to squash them all into a single commit. I do this all on one branch, no merging to main or anything like that, just git rebase -i to collapse the commits. It almost always works perfectly, and I've been doing it for a couple of years.

But sometimes it hiccups, and I haven't been able to figure out why. It's rare; I haven't figured out what's happening, so reproducing it isn't an option yet. It goes like this: git rebase -i 60a7cc5 starts up my editor, and I mark the commits to squash together. Save and exit, then git tells me this:

error: Your local changes to the following files would be overwritten by merge:
    ClientApp/Trainer.swift
Please commit your changes or stash them before you merge.
Aborting
hint: Could not execute the todo command
hint: 
hint:     squash 4a98a7f8d482403c6ded9518c4b51cba328e0a8e Interim checkpoint
hint: 
hint: It has been rescheduled; To edit the command before continuing, please
hint: edit the todo list first:
hint: 
hint:     git rebase --edit-todo
hint:     git rebase --continue
Could not apply 4a98a7f... Interim checkpoint

But ClientApp/Trainer.swift isn't modified--I've committed everything and have a clean working tree before I even start the rebase. I do a git status and I don't see that file mentioned anywhere, but I get this instead:

interactive rebase in progress; onto 60a7cc5
Last commands done (4 commands done):
   squash 4a98a7f Interim checkpoint
   squash 997abfa Interim checkpoint
  (see more in file .git/rebase-merge/done)
Next commands to do (2 remaining commands):
   squash 4a98a7f Interim checkpoint
   squash bac5951 Most of the framework is in place; I mean it this time
  (use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'main' on '60a7cc5'.
  (all conflicts fixed: run "git rebase --continue")

nothing to commit, working tree clean

Notice it says "all conflicts fixed", although I haven't fixed anything. I discovered a while back that simply doing git rebase --continue causes the rebase to continue to completion, although sometimes it stops repeatedly on different commits, requiring further git rebase --continue.

This is worrying, it doesn't seem like a proper workflow, so I'm guessing I'm doing something wrong, but I don't have a clue what it might be. I've googled and looked around on SO for this kind of problem, but everyone is doing brain surgery with their rebasing. I'm just trying to squash some commits together, so it's hard to find anything that relates to my problem.

I seek suggestions on what might be causing it, what I might look for next time it happens, or, because it happened recently, what I might look for in the reflog to see why, or whatever

SaganRitual
  • 3,143
  • 2
  • 24
  • 40
  • 3
    It's not obvious, so a reproducer would help. Of course, given what's happening, you don't have a reproducer. That's certainly frustrating. Important background questions (though I don't think they'll help without a reproducer): what OS are you using, is your file system case-sensitive or not, and what version of Git are you using? – torek Mar 23 '21 at 21:48
  • 2
    One other thought: because rebase works by *copying*, you'll have a reproducer the next time you encounter it. Run `git rebase --abort` and you're back where you were before you started. Save the entire repository state as the reproducer. (This is way too big, but at least now you *have* one. Whittle it down later.) – torek Mar 23 '21 at 21:49
  • macOS Big Sur 11.2.3 with their default shell zsh 5.8, git 2.28.0. As it turns out, I guess zsh ignores case, which I realized just now since you asked. I'll keep an eye out for case issues, cheers – SaganRitual Mar 23 '21 at 21:51
  • Aborting it is a great idea, thanks again! – SaganRitual Mar 23 '21 at 21:52
  • 2
    macOS file systems generally ignore case (I doubt zsh specifically does so, it just passes these things through). Case-folding always sets off my suspicions about name changes (pathtofile/file => PathToFile/File, or vice versa) as there are a lot of corner cases here in Git. – torek Mar 23 '21 at 21:53
  • 1
    Does this answer your question? [Git rebase fails, 'Your local changes to the following files would be overwritten by merge'. No local changes?](https://stackoverflow.com/questions/5074136/git-rebase-fails-your-local-changes-to-the-following-files-would-be-overwritte) – AD7six Apr 23 '21 at 09:33

0 Answers0