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

On 10/13/2011 01:51 PM, arQon wrote:

Snipping the bug and focusing on one of the after-effects of the bug is,
unfortunately, not helpful to me unless I'm missing your point (which is
certainly possible).

git switched branches while there were uncommitted files. It's not supposed to
do this, ever, unless given -f or -m, and it broke the tree as a result. Even
*with* -f or -m, the behavior I described is incorrect.
The git docs seem to agree with me, which is why there's git stash. If the docs
are wrong, fine, though it seems pretty strange to have a change on BranchA
appear by magic "in" BranchB without any merging.

What I'm after is an understanding / explanation of how something that isn't
supposed to happen, does. I don't care if it's "Because I'm an idiot", "Because
git is broken", or even "Make sure your config has 'git.makebranchesworkproperly
= true' in it, the default is false". If there is no explanation for why git
switches branches when there are still uncommitted files, and there doesn't seem
to be, then it's a pretty catastrophic bug and fixing it would be a Good Thing.

*AFAICT*, committing *a* file is what triggers it.
If you commit -a, which is what all the commits prior to this were, it works
properly. You change branches, and the files on the disk become what they should
be.
If you commit nothing, you correctly get the "uncommitted files" error.
If you do a partial commit though, your tree breaks.

Like I say, if the man page, quote:
"If you have local modifications to one or more files that are different between
the current branch and the branch to which you are switching, the command
refuses to switch branches in order to preserve your modifications in context."

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.
Partly because nothing will be lost and partly because you can just switch
branches back if you decide you've switched branches before committing things
to the first branch.

is wrong, and this behavior is deliberate, that's fine. Bizarre, but fine in
the sense that git is doing what it's supposed to (regardless of how
counterintuitive and destructive it is).
If the man page is right though, this is a bug. Maybe it's only in msysgit,
but this is the second time it's happened, so hopefully it's fairly easy to
reproduce.

It's not a bug. You just read the manpage a bit wrong.

Consider this scenario:
$dev works on featureA on branchA, modifying fileX, fileZ and fileY and then
does a commit of fileZ and fileY, but realizes that the changes in fileX
will be good for developing featureB as well, so he changes to a separate
branch to do the update to fileX and be able to merge those changes to
both branchA and branchB.

I've done this myself on numerous occasions when re-working small project-
local API's, and it's very, very handy indeed. If git would refuse me to
change branches without first committing everything I'd have to first
commit the change separately, switch branch, cherrypick the change, go
back to the first branch and remove the commit I made there, merge the
other branch where the commit really belonged and only then I could go
on about my business. If, on the other hand, I happen to switch branches
before committing fileZ in the above example, I can just switch back and
amend my last commit on the first branch.

So yes, this is a feature, and it's a handy one.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.