From: arQon <arqon@gmx•com>
To: git@vger•kernel.org
Subject: Re: [BUG] git checkout <branch> allowed with uncommitted changes
Date: Thu, 13 Oct 2011 18:19:26 +0000 (UTC) [thread overview]
Message-ID: <loom.20111013T193054-868@post.gmane.org> (raw)
In-Reply-To: 1318525486.4646.53.camel@centaur.lab.cmartin.tk
Carlos Martín Nieto <cmn <at> elego.de> writes:
> 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.
Right, but only for a definition of "branch" that is actually "a fully
committed branch", hence the confusion and the mention of "uncommitted
changes" in the topic.
An expectation that "co branch" should be analogous to "cd ../branch/" is by
no means unreasonable. YOU may know better, but it's surprisingly non-obvious,
especially considering the -f option on checkout and the wording of -m, both
of which strongly suggest that, in the absence of either of those flags, git
WILL preserve the worktree by refusing to switch until that potentially-
harmful situation is resolved by the user.
> Committing non-working code is fine, as long as you don't push it out.
Right, but for the problem I was describing it's actually "committing
non-working code is a requirement, in this situation, if you don't want your
tree to get eaten". Going from "you absolutely must not do this" to "you must
do this" takes some mental adjustment, but you also have to be *aware* that
you now have to do something that was previously prohibited, which I wasn't.
> The bigger problem seems to be your reluctance to accept that git is
> different from subversion
Not at all. If I didn't WANT something different, I wouldn't have been trying
to move to git in the first place. :)
> but don't go around saying that git
> corrupts branches when that's blatantly not true.
See my first para in this post (or indeed, the original post). It's "not true"
provided all branches are fully committed when you switch between them.
It blatantly IS true if you switch from a dirty branch.
Redefining "branch" to mean "fully committed branch" makes it "not true" in
that context, but so does redefining green to be red and saying that grass is
red in that context: it may be correct from a certain POV, but it's
incomprehensible to anyone who isn't aware of that semantic change.
Anyway, I think we're done with this thread. Thanks for your (key) observation
earlier and several clarifications, and hopefully this will help the next guy
who runs into this problem and gets confused like I did. :)
next prev parent reply other threads:[~2011-10-13 18:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 8:40 [BUG] git checkout <branch> allowed with uncommitted changes arQon
2011-10-13 10:48 ` Nguyen Thai Ngoc Duy
2011-10-13 10:59 ` Alexey Shumkin
2011-10-13 11:51 ` arQon
2011-10-13 12:22 ` Andreas Ericsson
2011-10-13 13:09 ` arQon
2011-10-13 13:59 ` Carlos Martín Nieto
2011-10-13 17:09 ` [CLOSED] " arQon
2011-10-13 18:56 ` Alexey Shumkin
2011-10-13 19:01 ` Jakub Narebski
2011-10-13 13:58 ` [BUG] " arQon
2011-10-13 14:46 ` Carlos Martín Nieto
2011-10-13 15:53 ` arQon
2011-10-13 16:17 ` Alexey Shumkin
2011-10-14 6:51 ` Alexey Shumkin
2011-10-13 16:32 ` Holger Hellmuth
2011-10-13 17:04 ` Carlos Martín Nieto
2011-10-13 18:19 ` arQon [this message]
2011-10-13 18:28 ` Junio C Hamano
2011-10-13 18:56 ` arQon
2011-10-14 1:38 ` Jeff King
2011-10-14 9:27 ` Holger Hellmuth
2011-10-14 9:54 ` Victor Engmark
2011-10-16 18:25 ` arQon
2011-10-16 20:37 ` Junio C Hamano
2011-10-16 22:04 ` Holger Hellmuth
2011-10-13 20:07 ` Carlos Martín Nieto
2011-10-13 17:06 ` Sergei Organov
2011-10-13 19:44 ` PJ Weisberg
2011-10-13 16:08 ` Holger Hellmuth
2011-10-13 12:42 ` arQon
2011-10-13 12:55 ` Holger Hellmuth
2011-10-13 14:44 ` Victor Engmark
2011-10-13 16:17 ` arQon
2011-10-14 7:16 ` Victor Engmark
2011-10-13 15:09 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20111013T193054-868@post.gmane.org \
--to=arqon@gmx$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox