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. 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, 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. > 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. > 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. It blatantly IS true if you switch from a dirty branch. 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. Anyway, I think we're done with this thread. Thanks for your (key) observation earlier and several clarifications, and hopefully this will help the next guy who runs into this problem and gets confused like I did. :) -- 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