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

[Holger Hellmuth <hellmuth@ira.uka.de>]

On 14.10.2011 03:38, Jeff King wrote:
> On Thu, Oct 13, 2011 at 06:56:14PM +0000, arQon wrote:
>
>> I'll give a shot, though I don't know how good it'll be. Off the top of my
>> head, I don't see any good way to explain the inconsistency with LOCAL CHANGES
>> sometimes preventing switches and sometimes not, based on what is to the user
>> an arbitrary set of rules that has nothing to do with the *current state* of
>> the worktree, but rather the state of those files in prior commits.
>
> The rules are fairly straightforward.

They are. But what arQon is getting at is that the normal switchability 
depends on something that is often a game of chance: Did I change a file 
that is different between the two branches? That is only known by the 
user for branches not far removed.

Now the obvious answer is: It doesn't matter because git tells you. At 
the right time to act upon it. But git says "M file" instead of what 
'git status' would say: "#  modified:   file". Is there a reason for 
that? On one hand it should be familiar to svn users, on the other hand 
it is an inconsistency. And personally I always hated those cryptic 
status flags of svn

Another good point arQon made is that the case that you switched with 
forgotten local changes is more common than the case that you switched 
because you made changes in the wrong branch. If that were the case the 
warning that you have local changes should be more visible than that 
small "M file", at best something that looks similar to 'git status' output.

Now what really is more common depends on the individual. If you are a 
beginner or a semi-frequent user, then forgetting local changes is 
probably far more common, wheras most people on this mailing list would 
say its the other way round. It much depends on your commit frequency 
because the more often you commit, the less likely is that you would 
forget local changes.