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