Re: My first git success [not quite]

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 14 Jan 2006, walt wrote:
>
> 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