[Bug?] uncommited changes cross branches

[Bug?] uncommited changes cross branches

[Rhodes, Kate]

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

Re: [Bug?] uncommited changes cross branches

[Johannes Schindelin]

Hi,

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

> 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.

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

Re: [Bug?] uncommited changes cross branches

[Rhodes, Kate]

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

> Hi,
>
> On Tue, 5 Feb 2008, Rhodes, Kate wrote:
>
>> 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.
>
> 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.

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