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

From: Holger Hellmuth <hellmuth@ira.uka.de>
Date: Oct 14, 2011, 09:27 UTC
Message-ID: <4E980093.6040704@ira.uka.de>
In-Reply-To: <20111014013830.GA7258@sigill.intra.peff.net>

On 14.10.2011 03:38, Jeff King wrote:

Show 9 quoted lines

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