Re: My first git success [not quite]

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 14, 2006, 21:57 UTC
Message-ID: <Pine.LNX.4.64.0601141350590.13339@g5.osdl.org>
In-Reply-To: <dqbnl1$3si$1@sea.gmane.org>

On Sat, 14 Jan 2006, walt wrote:

Show 12 quoted lines

>
> Linus Torvalds wrote:
> [...]
> > Now, what happens is that when you change branches with a dirty tree, the 
> > "git checkout" will do one of two things:
> > 
> >  - if the dirty files are _identical_ in both branches...
> 
> I'm sorry to be quibbling over semantics, truly I am!  But here
> is my confusion:  if modified-but-uncommitted (hence dirty) files
> are not associated with *any* branch, then how could 'dirty' files
> be 'in' both branches (or 'in' any branch at all)?

The file itself is associated with the branch. It's just that the _dirty_ part isn't.

Of course, you can also truly have files that aren't associated with either branch at all: files that haven't gotten committed at all. They're also "dirty state", and exactly like modifications to known files, they are carried along with the switch, so they'll exist in the directory tree after a "git checkout".

Anyway, in git, a "branch" is technically really nothing more than "top of a commit chain". If you look into the files that describe a branch, you'll literally just find the name of the top commit. Do a

	cat .git/refs/heads/master

to see.

So anything that isn't described by that commit is by definition "dirty state", whether it's because you've edited something (but not checked it in) or because there's some random generated file in the working tree.

So when you switch branches, you really should think of it as "ok, the committed state was switched around", and everything else was just "moved along".

		Linus