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

From: Carlos Martín Nieto <cmn@elego.de>
Date: Oct 13, 2011, 14:46 UTC
Message-ID: <1318517194.4646.30.camel@centaur.lab.cmartin.tk>
In-Reply-To: <loom.20111013T152144-60@post.gmane.org>

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

Show 8 quoted lines

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

I have not seen a revert command in any of your messages. If a revert on one branch changes another one, that would be a bug, but you haven't shown this to happen.

Show 8 quoted lines

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

Do not confuse a branch with a worktree. If you haven't committed yet, those changes aren't in the branch (just like they wouldn't be in svn)

Show 5 quoted lines

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

I've just asked some subversion developers to confirm this, and then tried it out myself: Subversion (my locally-installed version is 1.6.17, latest stable) behaves the same way. Local modifications are carried over across branches.

$ svn copy ^/trunk ^/branches/somebranch # Create a new branch $ $EDITOR somefile # which exists in trunk and somebranch $ svn switch ^/branches/somebranch $ svn diff # My local changes are there!

The reason this happens both in svn and git is that the most likely cause for someone to change a branch mid-edit is that they decide they're doing the changes on the wrong branch. What I did notice is that svn doesn't tell you about the modifications being carried over (presumably you're meant to use status and diff to figure out what's going on). Therefore, the same workflow (with the only difference being how to create and switch branches) works for svn and git in this case.

cmn