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

From: arQon <arqon@gmx.com>
Date: Oct 13, 2011, 15:53 UTC
Message-ID: <loom.20111013T171530-970@post.gmane.org>
In-Reply-To: <1318517194.4646.30.camel@centaur.lab.cmartin.tk>

Carlos Martín Nieto <cmn <at> elego.de> writes:

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

Sorry, it was in prose in the original post (near the end) "At this point, reverting the master with "checkout --" also wipes out the changes on the other branch. It's like the merge symlinked the two branches rather than, well, merging them."

Based on the explanations here, and the git *st* message, it wiping out the other branch is to be expected, because it's "the working directory", not "the branch".

>git st

# On branch foo # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: file1.txt # no changes added to commit (use "git add" and/or "git commit -a")

What makes this really interesting though is this: I tried to switch to master to see if that gave the same warning, and NOW, I get the correct error.

>git co master

error: Your local changes to the following files would be overwritten by
checkout:
        file1.txt
Please, commit your changes or stash them before you can switch branches.
Aborting

I'm sure if I thought about it enough (ie re-read Andreas's post a couple more times) I'd be able to understand why git gets it right sometimes but not other times, but I'm too tired right now. Even when I *am* awake and grok it properly, I'm still going to be annoyed that it's so inconsistent, but I can live with that if I have to.

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

Lucky you. :P The most likely reason for me is, I'm working on something and I get interrupted and have to switch. Since the code may well not even compile at this point, the last thing I want to do is commit it. git's ability for that commit to be local is half the reason I'm trying to switch to it. (I'm not particularly keen on having to commit broken code to even a local repo, but that's still a hell of a lot better than having it pushed upstream as well).

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

I expect part of my confusion comes from using different workdirs for svn branches, ie "clone" rather than "branch", because branching in svn is such a PITA I just don't bother with it unless the branch is going to be "heavyweight" enough to warrant a "proper" branch. Good to be reminded of though, thanks.