Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch

Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch

[Stian Haklev]

Newbie to git, but I've been reading up on the docs and I really love
both the theory and what it let's you do (still confused by some
issues like rebasing and stuff). For now I mostly use it on my own
small projects (where I frequently make branches, merge, cherry-pick
etc), and also push it to  repo.or.cz.

One confusing thing to me is that if I am in a clean state (no updated
files in working dir), and I checkout another branch (or another
treeish), sometimes git doesn't update the working dir, and sometimes
it does. So for example in my own repo I do

~wiki/> git status
no files updated

~wiki/> git checkout trying-new-feature
checked out

~wiki/> git status
no files updated

(this is how it should be obviously - the working dir reflects the
index which is now pointing at trying-new-feature, but then...)

~wiki/> git checkout master
checked out

~wiki/> git status
it then puts me directly into commit mode, with every file having a
ton of differences - because the files are still from
trying-new-feature and the index is pointing at master.

It also seems to do inconsistent things with files that exist in only
one of the branches - ie if switching back the file remains in the
directory but is now an "untracked" file, etc.

Maybe I am completely misunderstanding and there is something I should
do differently. It works out if I do git reset --hard, but it just
seems so uneccessary. (As I said, in all cases the working dir is
completely clean before doing the checkout).

thank you
Stian

Re: Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch

[Andy Parkins]

On Monday 2007 May 21, Stian Haklev wrote:

What does "git --version" say?

> ~wiki/> git checkout trying-new-feature
> checked out
> ~wiki/> git status
> no files updated
> ~wiki/> git checkout master
> checked out
> ~wiki/> git status
> it then puts me directly into commit mode, with every file having a
> ton of differences - because the files are still from
> trying-new-feature and the index is pointing at master.

Something has gone very wrong here.  You are right to be confused, that is not 
what one would expect from git.  After a git-checkout you should expect that 
the index is clean.

Did you get any error messages during any of those operations?

Are you sure you aren't doing something like
  git checkout trying-new-feature -- list of files
As that would update the working tree but not the current HEAD, and would 
therefore appear as changes to master.

When you do the final git-status, are the files being listed in the "Changed 
but not updated" section or the "Changes to be committed" section?

Can you make a minimal test case? e.g.
 mkdir testing-git; cd testing-git
 git init
 date > file1
 git add file1
 git commit -a -m "step1"
 date >> file1
 git commit -a -m "step2"
 git checkout -b newbranch HEAD^
 date >> file1
 git commit -a -m "step3"
 git checkout master
 git checkout newbranch
 git status



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch

[Stian Haklev]

OK, I made the following script:

do.sh:
git --version > ../file1
date >> ../file1
git status >> ../file1
echo checking out works with old >> ../file1
git checkout works-with-old >> ../file1
git status >> ../file1
git checkout master >> ../file1
git status >> ../file1
date >> ../file1

I ran it, and I got the following result:
nurhaliza:~/wiki stian$ less ../file1
git version 1.5.2.14.g45bde
Tue May 22 11:05:19 WIT 2007
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       do.sh
nothing added to commit but untracked files present (use "git add" to track)
checking out works with old
# On branch works-with-old
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       do.sh
nothing added to commit but untracked files present (use "git add" to track)
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    NOTES
#       modified:   display-page.rb
#       deleted:    eee_darwin
#       modified:   gui.rb
#       modified:   htmlshrinker-data.rb
#       modified:   htmlshrinker.rb
#       modified:   mongrel-web-gui.rb
#       modified:   mongrel-web.rb
#       modified:   zarchive.rb
#       new file:   zcompress.rb
#       modified:   zdump-7z.rb
#       modified:   zdump.rb
#       modified:   zipdoc.rb
#       deleted:    zutil.rb
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       do.sh
Tue May 22 11:05:20 WIT 2007

...

I should add that I am working in OSX 10.4.9.

Thank you,
Stian

Re: Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch

[Andy Parkins]

On Tuesday 2007 May 22, Stian Haklev wrote:

> git --version > ../file1

Good stuff.  The ">" only redirects stdout to file1; stderr would still be 
written to your terminal - did you notice any errors from this script?  Could 
you run again, but append "2>&1" to the end of each redirecting line?

> git status >> ../file1
Seemed fine after this.

> echo checking out works with old >> ../file1
> git checkout works-with-old >> ../file1
Seemed fine after this.

> git status >> ../file1
Seemed fine after this.

> git checkout master >> ../file1
> git status >> ../file1

Kaboom!

> # On branch master 
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #       deleted:    NOTES
> #       modified:   display-page.rb
> #       deleted:    eee_darwin
> #       modified:   gui.rb
> #       modified:   htmlshrinker-data.rb
> #       modified:   htmlshrinker.rb
> #       modified:   mongrel-web-gui.rb
> #       modified:   mongrel-web.rb
> #       modified:   zarchive.rb
> #       new file:   zcompress.rb
> #       modified:   zdump-7z.rb
> #       modified:   zdump.rb
> #       modified:   zipdoc.rb
> #       deleted:    zutil.rb

Wow.  I've never seen anything like that.  Neither the index nor the working 
tree has actually been updated - but HEAD now points at master.

What was the output of that last git-checkout (unfortunately it outputs to 
stderr not stdout, so you'll need the "2>&1" at the end of each line in your 
script)?  git-checkout won't change HEAD unless the change of index and 
working tree worked.  I can't see the path through the git-checkout script 
that would have done what you're describing.  I think it's going to need a 
guru on this one, however, we'll keep at it until I can't think of any more 
questions :-)

Do you observe the same behaviour on all repositories or just this one 
particular repository?

What's the form of this repository?  That is to say, is works-with-old a 
branch from master or is it an independent branch?  e.g.

  0 -- * -- * -- * (master)             0 -- * -- * -- * (master)
                                    or        \
  0 -- * -- * -- * (works-with-old)            * -- * -- * (works-with-old)
                     
I assume once you get into this broken state that running "git-reset --hard" 
restores the working tree back to master?

Does changing that last checkout to "git-checkout -f master" improve things?


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com