Re: [BUG] git checkout <branch> allowed with uncommitted changes

[arQon <arqon@gmx.com>]

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?