Is it possible to git stash an interactive rebase in progress?

Question

I am currently rebasing origin/master onto a branch that was created from origin/master a while ago and the developer that worked on the branch is not available right now.

I have resolved some conflicts on the first commits of the feature branch but come to a point where I must wait for the developer to know how to finalize the rebase.

Is there a way to keep the conflict resolution I already did (~30 minutes) so that I can move on to another task?

Answer 1

Or another idea is to commit and make a branch mid-rebase, then git cherry-pick remaining the un-rebased commits onto it later.

Answer 2

Another brain-dead simple solution is to simply copy the entire folder containing the git repository, mid-rebase. This should always work. May be a good idea to delete that folder when done (rebased and pushed).

Answer 3

In future, you can use rerere, which will record your resolutions. This won't instantly get you back to 30 minutes into the rebase, but it should help a lot, basically you just confirm your resolutions up to the point where you stopped. I don't know why rerere doesn't come as standard with Git, it's so useful.

Answer 4

All that git stash does is make a commit. (Well, two commits, but that doesn't matter just at this point. The commits git stash makes are on no branch, and are structured oddly, but the key is that it makes commits. That's because commits are the way to save files in Git. Even Git's git notes are commits! Like stashes, they are not on branches, but they do save files, so they are commits.)

If you can make a commit with git stash, you can make a commit with git commit.

If not—if you have not completed the resolution of the merge conflicts—you are basically stuck. You must resolve all the conflicts before you can commit. See How can I save a git "rebase in progress"? for (much) more about this.

Note that if you have a new enough Git to have git worktree add, you can set up multiple work-trees, each on a different branch. Each work-tree gets its own index (see that other question and answer for why this is important), so it's possible to leave an in-progress rebase with merge conflicts in "the" index and switch to another branch in another work-tree and do ordinary work. In other words, "the" index is now a per-work-tree index, so the fact that the merge conflicts are in "the" index "locks up" that one work-tree, but not any others.