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

From: Carlos Martín Nieto <cmn@elego.de>
Date: Oct 13, 2011, 17:04 UTC
Message-ID: <1318525486.4646.53.camel@centaur.lab.cmartin.tk>
In-Reply-To: <loom.20111013T171530-970@post.gmane.org>

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

Show 40 quoted lines

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

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.

Show 12 quoted lines

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

Yes, this is a great feature of distributed systems. A local repo is where you experiment. Treat it as your own personal space to play around with things. Committing non-working code is fine, as long as you don't push it out.

Show 10 quoted lines

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

Then the issue is that you've changed the workflow but haven't adjusted for it. You can do this as well with the git-new-workdir. As I mentioned it has a few rough edges, but if you're going to use it to have a checkout of a particular branch, it shouldn't present any problems. That would be like your current workflow.

Another option is to clone with a reference which will create a brand new clone but will use the objects that you've already downloaded (or just clone locally). This can be more comfortable than using the new-workdir and will hardly put any strain on the filesystem.

The bigger problem seems to be your reluctance to accept that git is different from subversion, as you keep saying "that's just how git is" to back your claim that you can't trust git on a feature where subversion behaves the same way. If you'd rather use different directories for different branches, you can. That is not an aspect which you can point to and say that you can't migrate to git for that reason. If you're more comfortable with subversion, that's fine also, it's an excellent piece of software[0], but don't go around saying that git corrupts branches when that's blatantly not true.

cmn

[0] Whatever one may think about the merits of CVCS vs DVCS; that shouldn't come into the quality of the software.