Re: [Bug?] uncommited changes cross branches

From: Rhodes, Kate <masukomi@gmail.com>
Date: Feb 5, 2008, 20:34 UTC
Message-ID: <140813C2-123F-48CB-99CC-4E9A9B6C33B9@gmail.com>
In-Reply-To: <alpine.LSU.1.00.0802051502360.8543@racer.site>

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

Show 26 quoted lines

> 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