Can we "stash" a git rebase in progress

Question

Currently being in the process to git rebase a branch into an other (which needs some adaptations and much of time), we need to do a hotfix on production (an other branch).

Is there a way to :

Checkout that production branch without loosing all the work done in this rebase process?
Do the job on production branch + commit
jump back to that rebase process to be completed?

I don't think there is a built-in way to do this. You will have to manually back up `.git/rebase-apply` and `.git/ORIG_HEAD` and possibly other internal files, then abort the rebase to work on the other branch, then put the file you backed up back into place. It will be easier to simply clone the repo and do the hotfix on the clone, or to back up the whole repo before aborting the rebase. — Sven Marnach, Oct 05 '17 at 09:29

score 1 · Answer 1 · answered Oct 05 '17 at 09:34

1

I left the project as is and did a git clone of it to an other folder. I'll code and commit the hotfix into the production branch of that new folder and will push them back to the original project folder when ready.

answered Oct 05 '17 at 09:34

samb

1,713
4
22
31

There are some caveats with pushing to a non-bare repository, see e.g. https://stackoverflow.com/q/1764380/279627 – Sven Marnach Oct 05 '17 at 10:59

score 0 · Answer 2 · answered Oct 05 '17 at 15:05

The short answer is no. Some items, such as the index, the HEAD, and the in-progress rebase information, are stored in or associated with the work-tree.

You can, as you suggested in your own answer, make a new clone; or, with Git versions 2.6 or above, use git worktree add. (The git worktree feature appears in 2.5 but there was a brief rush of fixes followed by a longer trickle of smaller fixes, so this works best in the latest Git versions.)

What git worktree add does is create additional work-trees using the existing repository. This is similar to making a new clone, except that the underlying .git repository is shared directly. Each added work-tree has its own separate index, so instead of the index for the work-tree, you now have an index per work-tree. Instead of the HEAD, you have one HEAD per work-tree, and so on.

There is one hard restriction on git worktree add: each work-tree must be in a separate branch. So if your main work-tree, the one you are in the middle of rebasing, is on branch develop, your added work-tree cannot also be on branch develop. If you want or need that, go ahead and use a separate clone. (You never actually need it but the details on this get tricky.)

Can we "stash" a git rebase in progress

2 Answers2