If some changes are added to the index and there are some changes that are not added to the index, how do I swap this two sets of changes?
7 Answers
It think that this is easiest to do with temporary commits. When you have staged and unstaged commits, you have the possibility of conflicts when trying to reorder the changes.
Make a commit with the staged changes, create a branch for later use:
git commit -m "Saved staged"
git branch save-staged
Make a commit with the unstaged changes (if the unstaged changes include new files you may need to explicitly git add
them first):
git commit -a -m "Unstaged changes"
Rebase the unstaged changes onto the original HEAD (may involve conflict resolution):
git rebase --onto HEAD^^ HEAD^
Rebase the staged changes onto the unstaged changes (may involve conflict resolution):
git reset --hard save-staged
git rebase --onto HEAD@{1} HEAD^
Finally, reset the index to the (originally) unstaged changes:
git reset HEAD^
And move the branch pointer back to the original HEAD:
git reset --soft HEAD^
Removed temporary branch:
git branch -D save-staged

- 755,051
- 104
- 632
- 656
-
1@whitered: Open question: what are you having difficulty understanding? The man pages for reset, rebase and commit should describe all the options I've used in detail and the steps I use are supposed to be step-by-step logical actions? – CB Bailey Aug 26 '10 at 11:57
For a lower-level solution, you can use a bit of plumbing to talk directly to the index:
INDEXTREE=`git write-tree`
git add -A
WORKTREE=`git write-tree`
git checkout $INDEXTREE -- .
git clean -f
git read-tree $WORKTREE
What that does is build a couple of temporary tree objects in the git store, one for the index and one for the working copy. Then, it restores the old index and checks it out into the working tree. Finally. it resets the index to the version representing the old working tree.
I haven't tested this, so I'm not sure how well it handles added files in either the index or the working tree.

- 24,753
- 5
- 53
- 61
-
Thanks for the answer! This inspired me to make a better, scriptable version, and also to make another script that can stash only staged changes. – JesusFreke Jun 16 '13 at 21:26
The way with patches (it doesn't work for binary changes):
Save patches for both staged and unstaged states
git diff >> unstaged.patch
git diff --cached >> staged.patch
Apply originally unstaged changes
git reset --hard
git apply unstaged.patch
Stage this changes except the patch files
git add -A
git reset -- staged.patch unstaged.patch
Apply originally staged changes
git apply staged.patch
Remove patch files
rm staged.patch unstaged.patch
-
Interesting solution as well. +1. Just out of curiosity, did you re-try the updated version of my `git stash` answer? – VonC Aug 26 '10 at 14:57
-
1Yes, I have re-tried it, it works fine unless there are some new (untracked before) files staged. My variant with patches fails in this case too. – whitered Aug 27 '10 at 12:11
This is based on Walter Mundt's answer, but works better when new files are staged. This is intended to be used as a script, e.g. git-invert-index
#!/bin/sh
# first, go to the root of the git repo
pushd `git rev-parse --show-toplevel`
# write out a tree with only the stuff in staging
INDEXTREE=`git write-tree`
# now write out a tree with everything
git add -A
ALL=`git write-tree`
# get back to a clean state with no changes, staged or otherwise
git reset -q --hard
git clean -fd
# apply the changes that were originally staged, that we want to
# be unstaged
git checkout $INDEXTREE -- .
git reset
# apply the originally unstaged changes to the index
git diff-tree -p $INDEXTREE $ALL | git apply --index --reject
# return to the original folder
popd

- 1
- 1

- 19,784
- 5
- 65
- 68
-
(Note that as written, this may remove some empty subdirectories from the working copy during the git clean. Given git's general disregard for empty directories, this may be difficult to avoid.) – Walter Mundt Jun 17 '13 at 20:15
-
Why are you using "diff-tree | apply; add -A" instead of "checkout $INDEXTREE -- ."? Note that checkout with a tree does not change your branch, so the two should have the same net effect, but checkout should be way faster since it doesn't have to build and parse a patch file and then rescan the working tree to backfill the index. – Walter Mundt Jun 17 '13 at 20:17
-
For the first diff-tree, you want the changes between saved INDEXTREE and ALL trees. Just checking out either isn't what you want. For the second case, using git checkout adds the changes from INDEXTREE into the index, but they should be unstaged – JesusFreke Jun 17 '13 at 21:51
-
@WalterMundt thanks for taking a look though. I hadn't considered git checkout at the time, and I'm always open to suggestions :) – JesusFreke Jun 17 '13 at 21:54
-
It looks like checkout can work for the unstaged changes, if you do that before the staged changes. Updated the script. Thanks! – JesusFreke Jun 17 '13 at 22:00
-
Maybe you don't need `pushd`/`popd` anymore. From `git help add`: "If no pathspec> is given when -A option is used, all files in the entire working tree are updated (old versions of Git used to limit the update to the current directory and its subdirectories)." – Joshua Goldberg Jan 30 '22 at 16:56
-
Can you say why this works better with new files in the index? Also, I think the `git add -A` will mix untracked files with the unstaged changes. (Running this with nothing staged leaves all untracked in the index at the end.) Perhaps it needs to be 3 steps (recording indices for add -u and add -A separately) in order to do what I'd expect in a swap, having no effect on untracked files in the end. – Joshua Goldberg Jan 30 '22 at 17:27
-
@JoshuaGoldberg At this point, I have no memory of why . My original answer just did a `cd` to the root directory, I wasn't even aware a modification had been submitted for it to use pushd/popd. But I agree, `git add -A` should work now, without needing to change the directory. The behavior with regards to untracked files matches my expectations, but feel free to take the script and modify it to suit your needs :) – JesusFreke Jan 30 '22 at 21:53
Charles Bailey has a more complete solution involving commits and managing potential conflict resolution.
I was originally trying to use only git stash
, except what I initially overlooked was that git stash
save will save both the index (staged changes) and the unstaged changes (which is inconvenient when you want to swap the index content with the unstaged changes).
So I modified to the following approach instead:
git commit
-m "temp commit" (create a commit for the current index)git stash
(stashing obviously what is not yet added to the index)git reset --soft HEAD^
(preserve the files previously committed)git stash
againgit stash pop stash@{1}
(applying not what you just stashed, but what you stashed before, i.e the initial changes that weren't yet added to the index)git add -A
git stash drop stash@{1}
to clean up the stash we previously applied ( stash@{0} still contains what was originally in the index)
At the end:
- what was not added to the index is now added.
- what was initially in the index ends up being stashed
-
`git stash` implies a `git reset --hard` so `git reset --mixed` is a no-op and the second `git stash` has nothing to do? – CB Bailey Aug 26 '10 at 11:05
-
@Charles: right. I have updated the answer to use `git stash --keep-index`. That way, the `git reset --mixed` has something to do ;) – VonC Aug 26 '10 at 11:24
-
OK, but not `git drop stash@{1}` surely isn't correct and if the last step in your process is `git add -A` then your not going to end up with any unstaged changes? I'm not convinced stash is the answer, it seems way to complex to get it right ;-) . – CB Bailey Aug 26 '10 at 11:28
-
1first step should be `git stash save --keep-index`, and I guess I have to apply the first stash before dropping it in step 4. Anyway this way does not work for me, because if I have 2 stashes and try to apply one of them, both of them become applied unexplainable – whitered Aug 26 '10 at 11:41
-
I just can't get the stash approach to work. The problem is that the second stash saves both changes (the working tree and HEAD never change between the two stashes), even if it records whether these were staged or not. Applying the second stash always applies both changes. – CB Bailey Aug 26 '10 at 11:44
-
Even if you do `git stash --keep-index && git checkout -- . && git stash && git stash pop stash@{1} && git stash pop` when you apply the second stash, if there are any auto-resolved conflicts stash uses the index to resolve the conflicts and the resolved file ends up staged anyway. – CB Bailey Aug 26 '10 at 11:48
-
@Charles: "Use git stash when you want to record the current state of the working directory **and the index** ". I had completely missed that little fact ;) Just for the fun of it, I have published another '`git stash`' version. – VonC Aug 26 '10 at 11:59
-
-
1@VonC You're welcome. :-) I really find this approach the most intuitive amongst the proposed answers, so I want to help others potentially also coming across it, to make it even easier to apply it successfully. It will also help me to have a good reference I will surely google my way to again later (after 6 months when I'll need it again and have forgotten the exact steps)! – Magne Jan 09 '18 at 12:36
It can be done in 3 steps:
git stash push -S
git add .
git stash pop
You can also wrap all of it in a command like so:
alias swap='git stash push -S && git add . && git stash pop'
Now you can simply execute swap
on the command line.

- 21
- 2
use `git rebase -i the best solution.
Alternative (too long):
Note the name of your current branch as:
<name-of-your-branch>
git checkout -b temp-unstaged
git commit -m "staged"
git branch temp-staged
git add .
git commit -m "unstaged"
git rebase --onto HEAD~2 HEAD~1
git checkout temp-staged
git rebase temp-unstaged
git reset HEAD~1
git reset --soft HEAD~1
git checkout <name-of-your-branch>
git branch -D temp-staged
git branch -D temp-unstaged
At last one can verify that the staged and untaged changes are swapped.

- 319
- 4
- 4