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

From: Carlos Martín Nieto <cmn@elego.de>
Date: Oct 13, 2011, 20:07 UTC
Message-ID: <1318536451.4646.79.camel@centaur.lab.cmartin.tk>
In-Reply-To: <loom.20111013T193054-868@post.gmane.org>

On Thu, 2011-10-13 at 18:19 +0000, arQon wrote:

Show 8 quoted lines

> Carlos Martín Nieto <cmn <at> elego.de> writes:
> > If file1.txt in the foo branch is different from the one in the master
> > branch, git will refuse to switch branches. 'git diff foo master' should
> > show that those two files are different.
> 
> Right, but only for a definition of "branch" that is actually "a fully
> committed branch", hence the confusion and the mention of "uncommitted
> changes" in the topic.

I'm not aware of any other definition of a branch, either for git or subversion.

> 
> An expectation that "co branch" should be analogous to "cd ../branch/" is by
> no means unreasonable. YOU may know better, but it's surprisingly non-obvious,

I don't see how. Switching branches is not the same as changing directories. It doesn't work that way, neither with git nor subversion. If you choose to have each branch in their own directory, that's fine, but it has very little to do with the VCS tool.

> especially considering the -f option on checkout and the wording of -m, both
> of which strongly suggest that, in the absence of either of those flags, git
> WILL preserve the worktree by refusing to switch until that potentially-
> harmful situation is resolved by the user.

The general description could probably benefit from a more explicit mention of what happens if there are local modifications. Currently it looks like it's only mentioned in the text of -f and -m, which is not particularly helpful.

Show 8 quoted lines

> 
> > Committing non-working code is fine, as long as you don't push it out.
> 
> Right, but for the problem I was describing it's actually "committing
> non-working code is a requirement, in this situation, if you don't want your
> tree to get eaten". Going from "you absolutely must not do this" to "you must
> do this" takes some mental adjustment, but you also have to be *aware* that
> you now have to do something that was previously prohibited, which I wasn't.

You can also have a different directory for the other branch if you really don't want to commit until it works. This is the same situation that you find yourself right now with subversion; I don't see how it's that hard to recognise that.

Show 12 quoted lines

> 
> > The bigger problem seems to be your reluctance to accept that git is
> > different from subversion
> 
> Not at all. If I didn't WANT something different, I wouldn't have been trying
> to move to git in the first place.  :)
> 
> > but don't go around saying that git
> > corrupts branches when that's blatantly not true.
> 
> See my first para in this post (or indeed, the original post). It's "not true"
> provided all branches are fully committed when you switch between them.

Right.

> It blatantly IS true if you switch from a dirty branch.

No. The branch has not been corrupted or changed at all. Your local modifications to files in the working tree were kept. Again, this happens both for git and svn.

> Redefining "branch" to mean "fully committed branch" makes it "not true" in
> that context, but so does redefining green to be red and saying that grass is
> red in that context: it may be correct from a certain POV, but it's
> incomprehensible to anyone who isn't aware of that semantic change.

This smells like FUD. A branch and a directory are two different things. If you find it more comfortable to use different directories for different branches that's fine, but that doesn't make it a branch. Changing a file doesn't automatically mean that that version of the file belongs to the currently active branch (or URL in the case for svn). A branch is only ever changed when you commit. This is something that holds true across VCSs. Play with subversion's 'switch' command, it behaves the same way.

cmn