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

["Carlos Martín Nieto" <cmn@elego.de>]

[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]

On Thu, 2011-10-13 at 13:09 +0000, arQon wrote:
> 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.

When you changed branches, git told you that a file had been changed in
the working tree. When you run 'git diff', it tells you the differences
between what you have in your working tree and what's in the branch[0].
Git is trying hard not to loose your modifications (maybe it was a
one-liner, maybe it was three hours of work) to the file.

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

It sound like you've misunderstood what a branch is for git. A branch is
only ever changed when you commit. What checkout does is change what the
current branch is. For a case like what you describe, the developer
would either do a temporary commit that they'd change later or stash the
changes[1]. You could also use git-new-workdir (from contrib/) so you
have two different directories that share the object storage. That has a
few rough edges, but if you restrict it to a broken branch, you
shouldn't have any problems.

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

Don't think of it as being "in" a branch. A checkout in git changes the
active branch. If there are any files that are different between the two
branches, they are changed. By switching branches with uncommitted
changes, you're telling git that you would rather use the other branch
to do your changes in. But git isn't doing this silently. After the
checkout, it lists the files that have local modifications, so the
developer can switch branches again and commit or stash the changes.

   cmn

[0] Really it's between the working tree and the index, but since you
just switched branches, the index is the same, and using it in that
sentence would just cause confusion.

[1] 'git stash' is a command that saves your uncommitted changes on a
stack so you can recover them later.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]