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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html