From: Victor Engmark <victor.engmark@terreactive.ch>
To: Holger Hellmuth <hellmuth@ira.uka.de>
Cc: Jeff King <peff@peff.net>, arQon <arqon@gmx.com>, git@vger.kernel.org
Subject: Re: [BUG] git checkout <branch> allowed with uncommitted changes
Date: Fri, 14 Oct 2011 11:54:47 +0200 [thread overview]
Message-ID: <20111014095447.GC2856@victor.terreactive.ch> (raw)
In-Reply-To: <4E980093.6040704@ira.uka.de>
On Fri, Oct 14, 2011 at 11:27:47AM +0200, Holger Hellmuth wrote:
> On 14.10.2011 03:38, Jeff King wrote:
> >On Thu, Oct 13, 2011 at 06:56:14PM +0000, arQon wrote:
> >
> >>I'll give a shot, though I don't know how good it'll be. Off the top of my
> >>head, I don't see any good way to explain the inconsistency with LOCAL CHANGES
> >>sometimes preventing switches and sometimes not, based on what is to the user
> >>an arbitrary set of rules that has nothing to do with the *current state* of
> >>the worktree, but rather the state of those files in prior commits.
> >
> >The rules are fairly straightforward.
>
> They are. But what arQon is getting at is that the normal
> switchability depends on something that is often a game of chance:
> Did I change a file that is different between the two branches? That
> is only known by the user for branches not far removed.
>
> Now the obvious answer is: It doesn't matter because git tells you.
> At the right time to act upon it. But git says "M file" instead of
> what 'git status' would say: "# modified: file". Is there a
> reason for that? On one hand it should be familiar to svn users, on
> the other hand it is an inconsistency. And personally I always hated
> those cryptic status flags of svn
>
> Another good point arQon made is that the case that you switched
> with forgotten local changes is more common than the case that you
> switched because you made changes in the wrong branch. If that were
> the case the warning that you have local changes should be more
> visible than that small "M file", at best something that looks
> similar to 'git status' output.
Very good point. How about by default just running `git status` after a
successful checkout, and only printing the result if there are any
changes? That way:
1) If no changes are pending, nothing is displayed.
2) The user sees a *familiar* style output if anything changed.
3) If there's an alias for "status", it would be used.
Example:
$ mkdir /tmp/test
$ cd /tmp/test
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ echo foo > foo
$ echo bar > bar
$ git add foo bar
$ git commit -m "Initial commit"
[master (root-commit) 55246c6] Initial commit
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 bar
create mode 100644 foo
$ echo foobar > bar
$ git branch --track test
Branch test set up to track local branch master.
$ git checkout test
M bar
Switched to branch 'test'
After `git checkout test`, we should instead see:
# On branch test
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: bar
#
no changes added to commit (use "git add" and/or "git commit -a")
2c,
V
--
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
next prev parent reply other threads:[~2011-10-14 9:55 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
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 [this message]
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=20111014095447.GC2856@victor.terreactive.ch \
--to=victor.engmark@terreactive.ch \
--cc=arqon@gmx.com \
--cc=git@vger.kernel.org \
--cc=hellmuth@ira.uka.de \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).