Simple testcase: >git init Initialized empty Git repository in C:/git-test/.git/ >notepad file1 >notepad file2 >git st # On branch master # Initial commit # Untracked files: # (use "git add <file>..." to include in what will be committed) # file1.txt # file2.txt nothing added to commit but untracked files present (use "git add" to track) >git add . >git st # On branch master # Initial commit # Changes to be committed: # new file: file1.txt # new file: file2.txt >git commit -am "init" 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 file1.txt create mode 100644 file2.txt >git co -b foo Switched to a new branch 'foo' >notepad file1 (edit stuff) >git st # On branch foo # Changes not staged for commit: # modified: file1.txt >git co master M file1.txt file1 now has the wrong data in it for "master" branch. If I go back to "foo" branch and commit the file before doing anything else, it recovers, and changing branches works correctly again. -- "If you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context." Maybe I'm just missing something obvious, but at the time that last "git co master" was issued: The file is locally modified. The file is different on the current branch (foo) than on the branch to which I am switching (master). The command fails to refuse to switch branches. So I guess the problem is that since the file wasn't re-added after the edit, git is ignoring it when trying to see if it's safe to branch or not? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html