Re: [Bug?] uncommited changes cross branches

["Rhodes, Kate" <masukomi@gmail.com>]

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