git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J.V." <jvsrvcs@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: git@vger.kernel.org
Subject: Re: Git: Unexpected behaviour?
Date: Fri, 11 Nov 2011 17:24:02 -0700	[thread overview]
Message-ID: <4EBDBCA2.7070603@gmail.com> (raw)
In-Reply-To: <4EBD9428.3030506@gmail.com>

OK so "work tree" is a new term for me.  I thought we were in isolated 
sandboxes called "branches" and changes made in a branch would stay in 
that branch regardless.

so anything in the "work tree" is over layed on top of my branch if 
there are no conflicts?

On 11/11/2011 2:31 PM, Chris Packham wrote:
> Hi,
>
> On 12/11/11 09:55, Jvsrvcs wrote:
>> Unexpected git behaviour
>>
>> ---
>> # First create a local git repo
>>
>> $mkdir gitexample
>> $git config --global user.name "my name"
>> $git config --global user.email "me@me.com"
>> $git init
>> $git add .
>> $git commit -m 'initial commit'
>>
>> # Create/Edit an empty file
>> $vi readme.txt
>>
>> # add a single line: "this was added in the master branch."
>> $git commit -a
> One thing to remember is that this is the same as "git add readme.txt"
> and "git commit" (I'll explain why below).
>
>> # create and checkout a new branch (from master)
>> $git branch test
>> $git checkout test
>>
>> # edit the readme.txt file and do not commit
>> # add the text:  "this was added in the test branch.", save and exit
>> $vi readme.txt
> At this point the changes are in the work tree. They aren't added to the
> test branch until you commit them.
>
>> #now switch back to master
>> $git checkout master
> When you have uncommited changes in the work tree that don't conflict
> with the contents of the branch you are checking out git will happily
> carry them along for you. If they did conflict then git would refuse to
> switch to the new branch.
>
>> $cat readme.txt
>>
>> #You will see both lines in the master.
>>
>> Question #1:
>> 	Why was this line added in the *master branch?
> Because the second change hasn't been committed it isn't in either
> branch. It's in the work tree.
>
>> --- even further surprising
>> In the master branch, now do a commit
>> $git commit -a
>>
>> cat readme.txt ( you will see the line in the master now that was added in
>> the test branch )
>>
>> Question #2:
>> 	Why did this happen?
> Because you asked for it to happen.
>
>> # Now switch back to the test branch
>> $git checkout test
>> $cat readme.txt
>>
>> You will only see the one line: "This was added in the master branch"
>>
>> Question #3:
>> 	Why did this happen?
> Because the second change was committed (in the master branch) it is
> no-longer floating in the work tree so when you switch branches you get
> the contents of the file in that branch.
>
>> and NOT the line added in that branch: "this was added in the test branch"
>> <= this line is gone
>>
>> What is the reason for this?
>>
>> 1) Why do I see uncommitted changes in the branches made off master in the
>> master branch?
>> 2) Why, if I commit them in the master, do the disappear in the branch in
>> which they were made?
>>
>> This is confusing, I would think the * master branch would be left
>> untouched.  This would solve issue #2.
>>
> Hopefully this will explain things a little better
>
> [work-tree] -- git add ->  [index] -- git commit -->  [HEAD]
>
> work-tree: the area on the file system where your code is checked out.
> index: also known as the staging area, this is represents what will end
> up in the next commit.
> HEAD: a general term for the current branch.
>
> As you can see that until a change is committed it isn't in _any_
> branch. When you type "git checkout test" or "git checkout master" HEAD
> will be updated. Changes in the work-tree or the index will be carried
> along (provided they don't conflict with the new HEAD).
>
> Hope that helps.
>
>

  reply	other threads:[~2011-11-12  0:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11 20:55 Git: Unexpected behaviour? Jvsrvcs
2011-11-11 21:03 ` Carlos Martín Nieto
     [not found] ` <CAPZPVFb-VbTfkuyg4KtTsaWiNvd37GHeH7crPtqv1fKRbwuyfQ@mail.gmail.com>
2011-11-11 21:04   ` Eugene Sajine
2011-11-11 21:09 ` Jvsrvcs
2011-11-11 21:14   ` Taylor Hedberg
2011-11-11 21:25   ` Gelonida N
2011-11-11 21:31 ` Chris Packham
2011-11-12  0:24   ` J.V. [this message]
2011-11-12  8:25     ` Chris Packham
2011-11-12 19:37     ` Junio C Hamano
2011-11-14 17:20       ` Martin von Zweigbergk
2011-11-14 20:55         ` Junio C Hamano
2011-11-14 21:33         ` Jakub Narebski
2011-11-12  8:32 ` Alexey Shumkin

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=4EBDBCA2.7070603@gmail.com \
    --to=jvsrvcs@gmail.com \
    --cc=git@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).