Git: Unexpected behaviour?

Git: Unexpected behaviour?

[Jvsrvcs]

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

# 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

#now switch back to master
$git checkout master
$cat readme.txt

#You will see both lines in the master.  

Question #1:
	Why was this line added in the *master branch?


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

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

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.


--
View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986736.html
Sent from the git mailing list archive at Nabble.com.

Re: Git: Unexpected behaviour?

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

On Fri, Nov 11, 2011 at 12:55:04PM -0800, Jvsrvcs wrote:
> Unexpected git behaviour
> 
[ ... switch branches with local modifications ...]
> #You will see both lines in the master.  
> 
> Question #1:
> 	Why was this line added in the *master branch?
> 

It wasn't. that line was added in the working directory. When you
switch branches, if the file in the tip of the current branch and the
file in the tip of the target branch don't differ, it's safe to keep
your local changes, so git does. This is to support the use-case where
you start editing a file when the wrong branch is checked out and want
to change to the right one.

> 
> --- 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 told git to commit the file with that modification in it.

> 
> # 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 file in the 'test' branch only has that line. As you said
yourself, you edited the file but didn't commit.

> 
> and NOT the line added in that branch: "this was added in the test branch"
> <= this line is gone

Again, that line wasn't added in any branch but in the working
directory. The active branch was 'test', but doesn't magically mean
that uncommitted changes travel with it.

   cmn

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Git: Unexpected behaviour?

[Eugene Sajine]

On Fri, Nov 11, 2011 at 4:01 PM, Eugene Sajine <euguess@gmail.com> wrote:
>
>
> On Friday, November 11, 2011, Jvsrvcs <jvsrvcs@gmail.com> 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
>>
>> # 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
>>
>> #now switch back to master
>> $git checkout master
>> $cat readme.txt
>>
>> #You will see both lines in the master.
>>
>> Question #1:
>>        Why was this line added in the *master branch?
>>
>>
>> --- 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?
>>
>> # 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?
>>
>> 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.
>>
>>
>> --
>> View this message in context:
>> http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986736.html
>> Sent from the git mailing list archive at Nabble.com.
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Possible dup, thanks to "smart" HTML filter:

 All described is absolutely expected and normal behavior for git. You just
 need to learn about it a bit more and understand what branch in git is and
 how it works with changes in working directory.
 it is best described in here http://progit.org/book/ch3-0.html

Re: Git: Unexpected behaviour?

[Jvsrvcs]

The thing is that I want my 'master' branch' to reflect what is in the
'master' repo - we are using another versioning control system than git for
the master for the moment. 

I want to be able to switch to the master at any moment, do an update there
with the primary versioning system in use, and get all others commits and
merge down to my branch from time to time.

It seems to me that this behaviour corrupts the master branch, reflecting a
change in the master branch that I did not want or expect.

so I suppose the correct work flow would to be *ALWAYS*, commit on the
branch you are on before switching to another branch?  I think this would
solve the problem.

This just seems a bit odd.  I did not commit on the branch, I switched and
it's on the master now.  At any rate, I can work with it, just need to know
the correct work flow I should take before switching to another branch, and
that seems to be *ALWAYS* commit before switching to get the expected
behaviour that seems normal to me.

--
View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986770.html
Sent from the git mailing list archive at Nabble.com.

Re: Git: Unexpected behaviour?

[Taylor Hedberg]

If you don't want to make a new commit on the branch you are leaving,
you can use `git stash` to stash away your working directory changes in
a temporary holding place without updating any branch.

Re: Git: Unexpected behaviour?

[Gelonida N]

On 11/11/2011 10:09 PM, Jvsrvcs wrote:
> The thing is that I want my 'master' branch' to reflect what is in the
> 'master' repo - we are using another versioning control system than git for
> the master for the moment. 
> 
> I want to be able to switch to the master at any moment, do an update there
> with the primary versioning system in use, and get all others commits and
> merge down to my branch from time to time.
> 
> It seems to me that this behaviour corrupts the master branch, reflecting a
> change in the master branch that I did not want or expect.
> 
> so I suppose the correct work flow would to be *ALWAYS*, commit on the
> branch you are on before switching to another branch?  I think this would
> solve the problem.

You can look at

git stash

> 
> This just seems a bit odd.  I did not commit on the branch, I switched and
> it's on the master now.  At any rate, I can work with it, just need to know
> the correct work flow I should take before switching to another branch, and
> that seems to be *ALWAYS* commit before switching to get the expected
> behaviour that seems normal to me.
> 
> --
> View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986770.html
> Sent from the git mailing list archive at Nabble.com.

Re: Git: Unexpected behaviour?

[Chris Packham]

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.

Re: Git: Unexpected behaviour?

[J.V.]

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.
>
>

Re: Git: Unexpected behaviour?

[Chris Packham]

On 12/11/11 13:24, J.V. wrote:
> 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?

Kind of. I'd say that your work tree is updated to match a branch when
you run git checkout initially. The branch is updated when you run git
commit (after staging changes in the index with git add or using -a).

Re: Git: Unexpected behaviour?

[Alexey Shumkin]

the same situation and question were discussed and explained one
month earlier
take a look
http://thread.gmane.org/gmane.comp.version-control.git/183464

> 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
> 
> # 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
> 
> #now switch back to master
> $git checkout master
> $cat readme.txt
> 
> #You will see both lines in the master.  
> 
> Question #1:
> 	Why was this line added in the *master branch?
> 
> 
> --- 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?
> 
> # 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?
> 
> 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.
> 
> 
> --
> View this message in context:
> http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986736.html
> Sent from the git mailing list archive at Nabble.com.

Re: Git: Unexpected behaviour?

[Junio C Hamano]

"J.V." <jvsrvcs@gmail.com> writes:

> 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.

Do not think of "branches" as isolated _sandboxes_.

Rather, "branches" are where the independent states are to be _recorded_.

The recorded states only exist in the git repository, and to use its
contents (e.g. view in the pager or browser, edit in the editor, run the
compiler on,...), you need to materialize the contents of the branch
somewhere on the filesystem. Such a set of files on the filesystem form
the working tree. The act of doing so is called "checking out a branch".

After you check out a branch, your working tree can be used to record an
updated state to the branch, but notice the "can be" part. Changes you
make to the working tree are _not_ associated to the branch until you make
them so by committing. They are floating on top of the branch you have
currently checked out in your working tree, and "floating" was the key
part lacking in your understanding that started this thread. You are
allowed to check out another branch while you have a local change in the
working tree, and this is deliberately so. People often start working on a
branch (that is, they want to make a change and check out a branch, or
they happen to have a check-out of a branch and then the find something
they want to change), and then realize that the change logically does not
belong to the currently checked-out branch but some other branch. They
need to be able to check out another branch without losing the change they
already made in their working tree, and for such usage, the workflow
should look like:

    $ git checkout master ;# on master branch
    $ edit hello.c ;# some feature being added
    ... realize that this change does not belong to the master
    ... branch but is part of the "hello" branch you have been
    ... working on for the past few days
    $ git checkout hello ;# check out the correct branch
    ... this keeps the local modification in hello.c (as long as
    ... the file you modified are the same between master and hello
    ... branches). Keep working on it and then finally...
    $ git commit ;# on hello branch.

There is another unrelated use case in which people have local changes in
their working tree, but need to check out a different branch. The most
common is while you are working on a large feature that is not finished
yet on your "feature" branch, you hear from your boss that one trivial fix
for an urgent bug must be committed and pushed out on the "master" branch.
The feature you have in your working tree does not have anything to do
with the bug or the fix you are going to make for your boss. In such a
case, you would want to save away the changes for the feature, check out
the "master" branch and commit the fix, i.e.

    $ git checkout feature ;# on feature
    $ edit foo bar baz ;# some complicated change
    ... boss comes

    $ git stash ;# stash away the current change
    or
    $ git commit -a -m 'wip'

    $ git checkout master ;# emergency
    $ edit ... ;# quickfix
    $ git commit -m 'urgent fix...'
    ... emergency dealt with

    $ git checkout feature
    ... back to what was being worked on

    $ git stash pop
    or
    $ git reset HEAD^

Re: Git: Unexpected behaviour?

[Martin von Zweigbergk]

On Sat, Nov 12, 2011 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "J.V." <jvsrvcs@gmail.com> writes:
>
>> 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.
>
> Do not think of "branches" as isolated _sandboxes_.
>
> Rather, "branches" are where the independent states are to be _recorded_.

I think I was confused about this when learning Git too. I friend of
mine made the following argument, which I agree with and which I haven
seen on the list before:

Either you want the modifications to stay on the branch, or you want
them to carry over to the branch you are checking out. In the former
case, you would want Git to fail if there are modifications (that you
might have forgotten you made). In the latter case, you would want
"git checkout -m". The current behavior is somewhere in between. It is
not clear to me if there is a use case where the current behavior is
better (from the user's point of view) than either failing or
"checkout -m".

It is obviously too late to change this now, though.

Martin

Re: Git: Unexpected behaviour?

[Junio C Hamano]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> Either you want the modifications to stay on the branch, or you want
> them to carry over to the branch you are checking out. In the former
> case, you would want Git to fail if there are modifications (that you
> might have forgotten you made). In the latter case, you would want
> "git checkout -m". The current behavior is somewhere in between. It is
> not clear to me if there is a use case where the current behavior is
> better (from the user's point of view) than either failing or
> "checkout -m".

Current behaviour is deliberately made safe because "checkout -m" may end
up forcing you to resolve a 3-way conflict you may not be prepared to do
correctly at your first attempt. Stopping and refusing to check out the
other branch gives you the choice to create a temporary stash-away commit
either on a current branch, or a temporary branch you create with "git
checkout -b temp && git commit" before switching to the target branch to
attempt to port the change over with "git cherry-pick @{-1}", which you
_can_ redo if you screw up conflict resolution and want to start over.
If you are confident that your local changes are trivial that you can
reproduce it even if you screw up your conflict resolution attempt, then
you can choose to run "checkout -m". If we made it the default, you will
lose this safety.

On the other hand, if you do *not* want to carry over the change when
checking out a different branch, you can easily stash-away the changes.

Re: Git: Unexpected behaviour?

[Jakub Narebski]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> On Sat, Nov 12, 2011 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > "J.V." <jvsrvcs@gmail.com> writes:
> >
> > > 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.

That would be the default and only solution if each branch was checked
out to a separate working directory.

You can do that in git using git-new-worktree script from contrib.

> > Do not think of "branches" as isolated _sandboxes_.
> >
> > Rather, "branches" are where the independent states are to be _recorded_.

Branches are lines of development, and are about _comitted_ changes.
This means that when switching branches "in place", un-committed
changes are not on any branch.

> I think I was confused about this when learning Git too. I friend of
> mine made the following argument, which I agree with and which I haven
> seen on the list before:
> 
> Either you want the modifications to stay on the branch, or you want
> them to carry over to the branch you are checking out. In the former
> case, you would want Git to fail if there are modifications (that you
> might have forgotten you made). In the latter case, you would want
> "git checkout -m". The current behavior is somewhere in between. It is
> not clear to me if there is a use case where the current behavior is
> better (from the user's point of view) than either failing or
> "checkout -m".

The "checkout -m" behavior is unsafe; you can land in a state where it
would be difficult to revert, and could lose your changes.  The
default behavior of switching branches is to carry over changes if it
is safe to do so.
 
> It is obviously too late to change this now, though.

Well, we could in theory add knob that would stash changes when
switching to branch, and unstash when switching to branch.

-- 
Jakub Narębski