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

From: arQon <[email-masked]>
Date: Thu, 13 Oct 2011 13:09:00 +0000 (UTC)

Andreas Ericsson <ae <at> op5.se> writes:
[snip]
> This means that if fileX on branchA is different from fileX on branchB and you
> *also* have local modifications to fileX, git will refuse to switch branches.
> If, on the other hand branchA:fileX == branchB:fileX and you have modifications
> to fileX in your work tree, there's no reason to refuse the branch change.

There's an EXCELLENT reason to refuse the branch change: once it happens, what
git is then telling is branchA, is not.

> It's not a bug. You just read the manpage a bit wrong.
[snip]
> So yes, this is a feature, and it's a handy one.

Thanks for the explanation. Unfortunately, I still can't see it as anything but
a critical bug. Consider this:

You're working on branchA and you have a bunch of uncommitted changes.
You can't remember some detail of the bug you're fixing, so you switch branches
to the master. You have to rebuild that branch, because your last build was from
your branch. git now builds the master with sources that were NEVER committed
to it. How is that not a total failure to maintain branch integrity?

If that's the way git is, then that's how it is; and if there isn't a setting
that can make it actually preserve branches properly, then there isn't. Which
sucks for me, because an SCCS that lies about what branch you're "really" on
is worse than useless, so I'm stuck with SVN.  :(

Thanks again for clearing it up for me though.