From: arQon <arqon@gmx•com>
To: git@vger•kernel.org
Subject: Re: [CLOSED] git checkout <branch> allowed with uncommitted changes
Date: Thu, 13 Oct 2011 17:09:11 +0000 (UTC) [thread overview]
Message-ID: <loom.20111013T181801-923@post.gmane.org> (raw)
In-Reply-To: 1318514356.4646.16.camel@centaur.lab.cmartin.tk
Carlos Martín Nieto <cmn <at> elego.de> writes:
> When you changed branches, git told you that a file had been changed in
> the working tree.
That's a very good point, if it was actually documented at all that that's
what it meant; and / or presented some warning that "BTW, if you edit this
file again now, it'll screw up your whole tree" instead of an innocuous "M";
and didn't appear to contradict what the manpage says about "local
modifications", we could probably have avoided half of this confusion. :P
As it was, when I saw that M suddenly appear after several days of bouncing
between branches without it and with everything working, I just thought
"oh great, git's managed to break this tree", because I remembered the same
thing from the previous trial run.
That there IS an indication though might just be enough for me to be able to
deal with it. Realistically, switching branches with uncommitted changes
(unless you're doing it because you've ALREADY screwed up and are changing
the wrong branch) is basically a trainwreck waiting to happen.
git stash appears to be useless for any nontrivial change on the *other*
branch, since there's no indication when you return to the stashed branch
there's a stash sitting around, which is not something you're going to
remember the next morning if fixing the master took the rest of the day,
and you're not going to use "stash list" by then either.
But as long as you get the "warning", an alias that does a "commit -am 'temp
commit to avoid git breaking the tree'" is something I think I can probably
live with.
Thanks for all the help guys - very much appreciated.
As far as I'm concerned, this topic's done.
(Though if someone can come up with a script / hook / whatever that improves
the "visibility" of stash, that would be awesome. Or one that makes the
refusal to switch branches consistent).
Looking at the manpage for checkout in the hope that there might be a "--safe"
switch, I don't understand why
"-f Proceed even if the index *or the working tree* differs from HEAD."
even exists, since it proceeds under those conditions anyway.
"--safe" appears to be exactly what the behavior should be if you DON'T
specify -f, except that -f nukes the working tree outright rather than just
bleeding it across. Hopefully it'll be clearer after some sleep. :)
next prev parent reply other threads:[~2011-10-13 17:09 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 ` arQon [this message]
2011-10-13 18:56 ` [CLOSED] " 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
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.20111013T181801-923@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