Konstantin, 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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
