Thanks a lot! That made me understand it perfectly! After your post I
went looking for more in depth info, and found the blog post "The
Three Trees of Git" on progit.org. The it all made sense!

Thanks a lot!!

On 11 Okt., 04:34, Konstantin Khomoutov
<flatw...@users.sourceforge.net> wrote:
> On Mon, Oct 10, 2011 at 03:48:24PM -0700, JP wrote:
> [...]
> > * I make some changes on the new branch. I do not commit or add these
> > changes to the staging area. I have both changed existing files and
> > added new files.
> > * Using the command "git checkout master" I switch back to my master
> > branch.
> > The changes I have made in the branch newLogin are visible in my
> > master branch. Switching branch does nothing. I would have expected to
> > see a master branch that did not have these changes.
> > If I then add these files to the staging area in master and switch
> > back to newLogin, "git status" will show exactly the same in every
> > branch.
> > What am I doing wrong? Have I completely misunderstood a very basic
> > concept in Git? I don't remember previous versions of Git acting like
> > this.
> Git had always behaved like this and yes, you're currently maintaining a
> wrong mental model about how Git works.
> In Git, "the work tree"--the set of files currently checked out, and
> "the index"--that sort of virtual thing which helps building the state
> which will be committed--are separate from any branch or, to put it
> differently, do not belong to any branch.
> This means, when you checkout a branch X, basically these things happen:
> 1) The files in the work tree are made to appear as in the tip commit on
>    the X branch;
> 2) The index is updated with that same information;
> 3) The reference named "HEAD" is updated so that now it points to the
>    branch X.
> So, when you commit, Git is only concerned with that HEAD reference: it
> updates whatever branch HEAD points to at the moment.
> When you have local unstaged changes or staged changes and try
> to switch a branch, Git does not automatically somehow stash away those
> changes because neither of them does belong to any branch yet:
> unstaged changes belong to the work tree and staged changes belong to
> the index, only when you commit (the staged changes) the resulting
> commit starts to belong to some branch.
> Git does have a special place called "the stash", and you can explicitly
> record your local edits there and later apply them to whatever state you
> checked out.
> So, it appears that in your mental model you perceive a branch as being
> some sort of complicated virtual thing but in fact a branch is merely a
> pointer to a commit and "being on a branch" merely means, very simply
> put, that the special ref "HEAD" is currently pointing at that branch.
> Hence it possibly helps to develop an understanding that when you think
> you're "working on a branch" you're *really* working in the work tree
> and with the index, and that "currently checked out branch" thing merely
> defines two things:
> 1) The state the work tree and the index start with;
> 2) Where the next commit you'll prepare will go into.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to