Re: [BUG] git checkout <branch> allowed with uncommitted changes
- From
Carlos Martín Nieto <cmn@elego.de>
- Date
- Oct 13, 2011, 13:59 UTC
- Message-ID
- <1318514356.4646.16.camel@centaur.lab.cmartin.tk>
- In-Reply-To
- <loom.20111013T144822-277@post.gmane.org>
On Thu, 2011-10-13 at 13:09 +0000, arQon wrote:
Show 9 quoted lines
> 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.
Show 13 quoted lines
> > > 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.
Show 5 quoted lines
> > 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.