threads / discuss / 28913

Git: Unexpected behaviour?

Subject: Git: Unexpected behaviour?

## tl;dr

14 messages between Nov 11, 2011 and Nov 14, 2011.

replies: 13people: 10as markdown or json

Jvsrvcs· Nov 11, 2011, 20:55 UTC · lore
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.

Carlos Martín Nieto· Nov 11, 2011, 21:03 UTC · re: Jvsrvcs · lore

Re: Git: Unexpected behaviour?

On Fri, Nov 11, 2011 at 12:55:04PM -0800, Jvsrvcs wrote:
> Unexpected git behaviour
> 
[ ... switch branches with local modifications ...]
Show 5 quoted lines
> #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.

Show 10 quoted lines
> 
> --- 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.
Show 9 quoted lines
> 
> # 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
Jvsrvcs· Nov 11, 2011, 21:09 UTC · re: Jvsrvcs · lore

Re: Git: Unexpected behaviour?

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.

Taylor Hedberg· Nov 11, 2011, 21:14 UTC · re: Jvsrvcs · lore

Re: Git: Unexpected behaviour?

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.

Gelonida N· Nov 11, 2011, 21:25 UTC · re: Jvsrvcs · lore

Re: Git: Unexpected behaviour?

On 11/11/2011 10:09 PM, Jvsrvcs wrote:
Show 14 quoted lines
> 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
Show 10 quoted lines
> 
> 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.
Chris Packham· Nov 11, 2011, 21:31 UTC · re: Jvsrvcs · lore

Re: Git: Unexpected behaviour?

Hi,
On 12/11/11 09:55, Jvsrvcs wrote:
Show 17 quoted lines
> 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).

Show 8 quoted lines
> 
> # 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.

Show 6 quoted lines
> $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.

Show 9 quoted lines
> --- 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.
Show 9 quoted lines
> 
> # 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.

Show 14 quoted lines
> 
> 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.
J.V.· Nov 12, 2011, 00:24 UTC · re: Chris Packham · lore

Re: Git: Unexpected behaviour?

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:
Show 102 quoted lines
> 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.
>
>
Chris Packham· Nov 12, 2011, 08:25 UTC · re: J.V. · lore

Re: Git: Unexpected behaviour?

On 12/11/11 13:24, J.V. wrote:
Show 6 quoted lines
> 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).

Junio C Hamano· Nov 12, 2011, 19:37 UTC · re: J.V. · lore

Re: Git: Unexpected behaviour?

"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^
Martin von Zweigbergk· Nov 14, 2011, 17:20 UTC · re: Junio C Hamano · lore

Re: Git: Unexpected behaviour?

On Sat, Nov 12, 2011 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> "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
Junio C Hamano· Nov 14, 2011, 20:55 UTC · re: Martin von Zweigbergk · lore

Re: Git: Unexpected behaviour?

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
Show 8 quoted lines
> 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.

Jakub Narebski· Nov 14, 2011, 21:33 UTC · re: Martin von Zweigbergk · lore

Re: Git: Unexpected behaviour?

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
Show 6 quoted lines
> 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.

Show 12 quoted lines
> 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
Alexey Shumkin· Nov 12, 2011, 08:32 UTC · re: Jvsrvcs · lore

Re: Git: Unexpected behaviour?

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

Show 73 quoted lines
> 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.
Eugene Sajine· Nov 11, 2011, 21:04 UTC · lore

Re: Git: Unexpected behaviour?

On Fri, Nov 11, 2011 at 4:01 PM, Eugene Sajine <euguess@gmail.com> wrote:
Show 81 quoted lines
>
>
> 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

← back to recent threads