Why are unstaged changes still present after checking out a different branch?

Question

I\'m observing something that is not consistent with what I know about the git checkout command. While on a branch other than master, I make some m

Answer 1

Until a change is staged (using git add), it just exists in the working directory - it is not tracked by git, and therefore will exist in any branch you checkout.

Answer 2

At first sight, your question seemed pretty uninteresting, but it made me realize that git checkout is not as simple an operation as it seems. Thanks for asking it :)

As I understand it, your question is: why are the uncommitted changes, i.e. the added foo line, still present in the working tree after checking out master? If you look up the git-checkout man page, you'll find the following description:

git checkout <branch>

    To prepare for working on <branch>, switch to it by updating the
    index and the files in the working tree, and by pointing HEAD at
    the branch. Local modifications to the files in the working tree
    are kept, so that they can be committed to the <branch>.

However, this description seems to contradict what's happening in your example. You're not the first one to be confused by it; see this discussion. In it, Junio Hamano, the maintainer of Git, clarifies what git checkout <commit-ish> does in the presence of local modifications:

The principle is that we allow you to check out a different branch when you have local changes to the working tree and/or to the index, as long as we can make the index and the working tree pretend as if you reached that locally modified state, starting from a clean state of the branch you are checking out.

---

Exegesis of Junio Hamano's response

What happens still wasn't clear to me, so I conducted a few experiments to fix ideas, and here is my interpretation of Junio Hamano's reply. First, let me introduce some terms: let

• Cs denote the source commit, i.e. the commit that HEAD points to before the checkout operation,
• Is denote the state of the staging area,
• Ws denote the state of the working tree,
• Ct denote the target commit, i.e. the commit that we're attempting to check out.

My understanding is that, when invoked, git checkout, for each tracked file, gets the following diffs,

• diff(Cs,Is) (which you can see in the output of git diff --staged),
• diff(Cs,Ws) (which you can see in the output of git diff),

and checks whether those changes apply cleanly on the target commit, Ct. If there is any conflict, the checkout operation is aborted. Otherwise, HEAD moves to Ct, and the states of the staging area (Is) and working tree (Ws) are preserved.

Application to your example

Before git checkout master

Right after the line

git commit -m "initial commit"

in your example, your repo looks like this:

The pages next to the commit, staging area, and working tree, symbolizes the contents of your README file in the correspondings three "Git areas".

"During" git checkout master

Then you run

git checkout master

So, under the assumption that my interpretation of Junio's anwer is correct, what happens here?

Because both the current branch, new-branch, and the branch to checked out, master, point to the same commit A, both Cs and Ct (using my terminology) correspond to A. In that case, of course, diff(Cs,Is) and diff(Cs,Ws) apply cleanly to Ct; no conflict here.

Therefore, the checkout operation is carried out:

• HEAD is made to point to master,
• the state of the staging area is preserved,
• the state of the working tree is preserved.

After git checkout master

Because no conflit arose when checking out master, local modifications to README in the working tree have been kept, so that they can be committed to the master branch.