>* When the branch head pointed by $GIT_DIR/HEAD changes while > the index file and working tree are looking the other way > (e.g. somebody pushed into your repository, or you ran "git > fetch" to update the ref your working tree is on), "git > checkout" without -f gets confused. Figure out a good way to > handle this.
Aha ... is this the problem that caught me out last week (when I ended up with 10 extra files attached to one of my commits)? At the time the blame was placed on a failed merge not being backed out correctly. But I only had the failed merge because "get checkout" had failed to switch branches (and not provided an exit code to stop my script from trying the merge). Here's what I did this morning. 1) Updated my "linus" branch: $ git checkout linus && git pull linus This appeared to work just fine ... except that when I check the status of my tree I see: $ git status # # Updated but not checked in: # (will commit) # # modified: arch/ia64/pci/pci.c # modified: arch/ppc64/kernel/setup.c # modified: arch/sparc64/kernel/pci.c # modified: arch/x86_64/defconfig # modified: drivers/block/cfq-iosched.c # modified: include/asm-m68k/page.h # modified: kernel/cpuset.c # # # On branch refs/heads/linus Which looks like a set of landmines just waiting for me to step on them! Today these didn't bite me. "git checkout release" worked and switched to my release branch (and git status went back to saying "nothing to commit"). But in the past I think this is the situation that has caused "git checkout" to fail with the "fatal: Entry 'blah' would be overwritten by merge. Cannot merge." -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
