Re: My first git success [not quite]

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 14 Jan 2006, walt wrote:
> 
> I see I still have a problem:  my mental model of how git
> works is still wrong.
> 
> I used 'git-checkout -b test' to create a disposable place
> to test the patch I was given.
> 
> Okay, making sure I'm now sitting in 'test', I apply the
> patch to foo.c and do my testing.
> 
> Now, intending to delete my 'test' branch, I do git-checkout
> master.  My mental model predicts that 'master' should still
> be identical to 'origin' because I did the patching in 'test'.
> Am I right so far?

Yes.

> The problem I see is that, after switching back to 'master',
> foo.c is the patched version, not your original version.

Ahh. This is very much done on purpose.

Something that hasn't been committed (it is "dirty" in git terms) is 
really not associated with any branch _at_all_. It's purely associated 
with the checked-out directory.

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, the dirty state 
   (remember: it's not associated with any particular branch) will follow 
   the branch switch.

   This is very convenient. You've edited a file, but you realized that 
   you did this in the wrong branch. For example, you realize that you are 
   in the main development branch, but that your edit is pretty damn 
   experimental. So what you do is _not_ to undo your edit, but to create 
   a new branch and switch to it, and then commit it _there_.

		git checkout -b experimental
		git commit --all

   (you might have an old experimental branch too, in which case you don't 
   need to create it, but then you can only switch to it if the file you 
   edited is the same as in your development branch)

 - otherwise, the switch will fail, and you'll have to either commit the 
   changes in that branch, or you'll have to undo them.

Now, Junio has patches (maybe they even got merged in mainline) to relax 
the "exactly the same" rule a bit, and instead try to merge any dirty 
state into the branch you're switching to. Conceptually nothing changed: 
dirty state is branchless, so when you switch to another branch, the dirty 
state follows you. 

> I figured that the git-checkout would overwrite any changes I
> made to foo.c, but that doesn't seem to be the case.  To get
> your original version back I had to delete foo.c and do a
> git-checkout foo.c (or git-checkout -f master).

Yes. You can either undo the dirty state, or you can do a "forced 
checkout" that will start from scratch. And the dirty state will be _gone_ 
in both cases. It won't be saved away in the "original branch". Again, 
this is 100% consistent with the notion that dirty state is branchless. 
Only _committed_ state is committed to a particular branch.

> So, I clearly don't understand what git-checkout does.  It
> doesn't seem to touch the already-checked-out sources at
> all, which is what I would expect it to do.

No, you understand exactly what git-checkout does, you just didn't realize 
that dirty state was different from committed state.

		Linus