[Bug?] uncommited changes cross branches

If you have a file that exists in two branches in the same repo, make a change to it without committing, then switch branches the changes carry over, but if you make changes to a file that exists in only one of the repos and try and switch branches Git complains that the file isn't uptodate. The latter behavior seems correct to me.

Changes I make in any branch should not just follow me around as I switch through other branches. It seems not only conceptually broken to me, but also something that make it very easy to accidentally commit changes to an unintended branch if you weren't paying close attention when you switched. I think that the appropriate action is to not allow a user to switch branches whenever there are files that aren't up to date (committing, git-stash, and checkout -m being the obvious, and safe, ways around the blockage).

The documentation *seems* to agree with me and it looks like it was the intent of the code to prevent this too, but it obviously doesn't.

In case my description was a little confusing below is a real world example of what I'm talking about. The last command is what I believe should not be possible:

$ temp krhodes$ mkdir foo
$ temp krhodes$ cd foo/
$ foo krhodes$ git --version
git version 1.5.4.2.g41ac4
$ foo krhodes$ git init
Initialized empty Git repository in .git/
$ foo krhodes$ echo "foo" > foo.txt
$ foo krhodes$ git add foo.txt
$ foo krhodes$ git commit -a -m " initial commit"
Created initial commit 10d7a21:  initial commit
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 foo.txt
$ foo krhodes$ git checkout -b branch_one
Switched to a new branch "branch_one"
$ foo krhodes$ echo "bar" > bar.txt
$ foo krhodes$ git add bar.txt
$ foo krhodes$ git commit -a -m "initial branch_one_commit"
Created commit 3251c16: initial branch_one_commit
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 bar.txt
$ foo krhodes$ echo "baz" > bar.txt
$ foo krhodes$ git checkout master
fatal: Entry 'bar.txt' not uptodate. Cannot merge.
$ foo krhodes$ git checkout bar.txt
$ foo krhodes$ git checkout master
Switched to branch "master"
$ foo krhodes$ echo "baz" > foo.txt
$ foo krhodes$ git checkout branch_one
M	foo.txt
Switched to branch "branch_one"

------- -masukomi

Hi,

On Tue, 5 Feb 2008, Rhodes, Kate wrote:

It is slightly different: if you change a file without committing _-and- the switch to another branch does not touch the file, git does not complain.

The rationale: git should refuse to switch branches _only_ if uncommitted changes would be lost.

However, if you change a file whose content is different in the other branch (and "not existing" qualifies), the uncommitted changes would be lost, and git should complain.

Ciao, Dscho

On Feb 5, 2008, at 10:07 AM, Johannes Schindelin wrote:

That makes sense, but I wonder if the distinction isn't a little too subtle for most users to pick up on without being told, and if letting uncommitted changes cross branches without some explicit user approval is a good idea. I assume that once someone becomes really used to working with multiple branches within the same repo you'd build up subconscious safeguards against accidentally pulling changes into a branch you didn't mean to, but I worry that it's going to be problematic for users starting out with git.

To me it's like the difference between -d and -D in git-branch. It's generally a good idea to use -d by default and have git warn you that you're about to do something that could screw you up.

-kate == masukomi