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

On Thu, Oct 13, 2011 at 04:17:51PM +0000, arQon wrote:

Victor Engmark <victor.engmark <at> terreactive.ch> writes:

quoted

1. `checkout master` and commit the fix there, then shift back and
continue working

I absolutely agree. And it's far more common than any of us would like.
My point is, you *can't* do this in git without first staging your current branch
via either commit or stash, or you risk changes bleeding between the branches
and/or work being lost irretrievably.

It's been pointed out enough times already that work is *not* lost (at
least unless you --force it to) *nor* the branches corrupted, so I'll
just advice to look at more Git documentation. I used CVS 2004-2006 or
so, Subversion 2006-2009, and Git since then. It's vastly superior to
either, and it's really difficult to lose any work unless getting into
the habit of forcing every change.

This is not something that you would
expect, and as you say:

quoted

The second most important thing a VCS should do is not destroy any of your

uncommitted work unless you tell it to

... which is exactly what git does, and why I have a problem with it.

No, it does not. Others have explained this better already.

But the response here is uniformly "that's just how git is", so obviously it's
something you learn to become aware of over time, and avoid. It's not going to
get "fixed", because people who are used to git don't see it as a bug, so I just
have to decide whether I can live with it or not.

It took a while to get my head around just how broken the Subversion
model was, and why my expectations from using that model kept resulting
in "weird" state (although don't get me started on `svn clean`). Don't
worry, you'll see the light :)

-- 
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch

Wir sichern Ihren Erfolg - seit 15 Jahren