git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).