What is the shortest way to swap staged and unstaged changes in git?

Question

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?

Airwaves

Here was my final solution (originally posted here https://mcmap.net/q/408720/-git-invert-staging-area) – Traynor

Answer 1

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

Barramunda

@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? – Barramunda

Answer 2

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.

Rydder

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. – Unapproachable

Answer 3

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

Airwaves

Interesting solution as well. +1. Just out of curiosity, did you re-try the updated version of my git stash answer? – Interglacial

Yes, 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. – Airwaves

Answer 4

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

Unapproachable

(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.) – Rydder

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. – Rydder

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 – Unapproachable

@WalterMundt thanks for taking a look though. I hadn't considered git checkout at the time, and I'm always open to suggestions :) – Unapproachable

It looks like checkout can work for the unstaged changes, if you do that before the staged changes. Updated the script. Thanks! – Unapproachable

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)." – Linter

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. – Linter

@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 :) – Unapproachable

Answer 5

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 again
• git 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

Interglacial

git stash implies a git reset --hard so git reset --mixed is a no-op and the second git stash has nothing to do? – Barramunda

@Charles: right. I have updated the answer to use git stash --keep-index. That way, the git reset --mixed has something to do ;) – Interglacial

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 ;-) . – Barramunda

first 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 – Airwaves

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. – Barramunda

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. – Barramunda

@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. – Interglacial

@Magne Thenk you for your edit and your work on this 8 years-old answer! – Interglacial

@Interglacial 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)! – Lumberman

Answer 6

Starting with Git 2.35, 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.

Dimitris

That won't work. Git is known for not being able to stash changes of files which have both staged and unstaged changes. That's the entire reason I want to swap in the first place, so I can, instead of the broken 1. stash 2. commit, I can 1. swap, 2. commit, 3. stash what I had originally staged. – Response

@MarkJeronimus I beg to disagree with your claim that Git is unable to stash files having both staged and unstaged changes. In any case, I think you should try the command first to verify that it works so that your response can be more realistic than idealistic. – Dimitris

I see that this was added in Git 2.35, which came out less than 2 years ago. I've had this problem for much longer and at that time there was no solution. Moreover, Git bundled with my Linux Mint is still at 2.25, as they are never very progressive (unless you have Arch or something). Time to see if there's a more up-to-date PPA. – Response

@MarkJeronimus Your comment is not quite precise. What feature/command exactly was added in Git 2.35? As of the version prior to that, which of the 3 steps I proffered will fail and why? What would be the error message? – Dimitris

Wait I just remembered. (I deleded my previous comment) It's the first command, and in old versions of git, it would stash all changes of a file if some of the changes are staged and some aren't. So unstaged changes of such files were included in the stash and the swap fails. – Response

Answer 7

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.

Erhard