All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: walt <wa1ter@myrealbox.com>
Cc: git@vger.kernel.org
Subject: Re: My first git success [not quite]
Date: Sat, 14 Jan 2006 12:49:43 -0800	[thread overview]
Message-ID: <7vbqyefsbc.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <dqbnl1$3si$1@sea.gmane.org> (wa1ter@myrealbox.com's message of "Sat, 14 Jan 2006 12:41:04 -0800")

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.

        

  reply	other threads:[~2006-01-14 20:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-13 14:51 My first git success walt
2006-01-13 17:11 ` Linus Torvalds
2006-01-13 18:57   ` Randal L. Schwartz
2006-01-13 19:37     ` Junio C Hamano
2006-01-13 20:14     ` Peter Eriksen
2006-01-14 15:39   ` My first git success [not quite] walt
2006-01-14 15:55     ` sean
2006-01-14 15:55       ` sean
2006-01-14 17:18         ` walt
2006-01-14 17:48           ` Randal L. Schwartz
2006-01-14 20:31             ` Junio C Hamano
2006-01-14 19:25     ` Linus Torvalds
2006-01-14 20:41       ` walt
2006-01-14 20:49         ` Junio C Hamano [this message]
2006-01-14 21:57         ` Linus Torvalds
2006-01-15 10:44       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vbqyefsbc.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=wa1ter@myrealbox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.