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

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

On Monday 2007 May 21, Stian Haklev wrote:

What does "git --version" say?

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

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

On Tuesday 2007 May 22, Stian Haklev wrote:

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?

Seemed fine after this.

Seemed fine after this.

Seemed fine after this.

Kaboom!

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