Re: [BUG] git checkout <branch> allowed with uncommitted changes
- From
- arQon <arqon@gmx.com>
- Date
- Oct 13, 2011, 13:58 UTC
- Message-ID
- <loom.20111013T152144-60@post.gmane.org>
- In-Reply-To
- <4E96D819.20905@op5.se>
Andreas Ericsson <ae <at> op5.se> writes:
> there's no reason to refuse the branch change. > Partly because nothing will be lost
Actually, this isn't true either, because of the second bug: doing a revert in branchA causes the changes in branchB to be lost. This can't possibly be the intended behavior: again, it completely violates the integrity of branches by allowing changes on one branch to impact a different branch.
Your interpretation of the manpage doubtless matches the actual behavior of git, but I find it staggering if that truly is what was intended. It basically means that if you have local modifications, git will Break Your Entire Tree. That makes changing while you *do* have local mods more than a little undesirable, to put it mildly, which is something that a literal reading of the manpage would suggest is exactly what the "refuse to switch" is for. I guess only Linus knows what he actually meant. :)
Anyway, I guess it's all moot: call it a feature or call it a bug, this cross- branch destruction is a deal-breaker for me, especially given the bug above that actually loses data outright, rather than "only" putting multiple branches into an incorrect state.
Thanks for your time and help.