From: Junio C Hamano <junkio@cox.net>
Date: Sat, 14 Jan 2006 20:49:43 GMT
Subject: Re: My first git success [not quite]
Message-ID: <7vbqyefsbc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <dqbnl1$3si$1@sea.gmane.org>

walt <wa1ter@myrealbox.com> writes:

> 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)?

"If the paths that you have dirty are the same in both
branches".

That is:

* "master" branch has Makefile file, as taken from git.git

* "my-work" branch was made out of "master" branch, but
  has not modified Makefile file.

	git-diff-tree master my-work Makefile

  would yield nothing.

* You are on "master" branch.  You have added a new target to
  your Makefile in the working tree and the path is dirty.

Then:

	git checkout my-work

would notice that the path "Makefile" are identical between two
branches "master" you are switching from and "my-work" you are
switching to.  The "Makefile" in your working tree does not
match either tree, but that difference is carried over while
switching branches.

As Linus mentioned, with '-m' flag to "git checkout", it can
merge your local modifications even when "master" and "my-work"
disagrees on "Makefile" in this example.