Re: My first git success [not quite]
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jan 14, 2006, 20:49 UTC
- Message-ID
- <7vbqyefsbc.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <dqbnl1$3si$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
Show 11 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)?
"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.