git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Victor Engmark <victor.engmark@terreactive.ch>
To: arQon <arqon@gmx.com>
Cc: git@vger.kernel.org
Subject: Re: [BUG] git checkout <branch> allowed with uncommitted changes
Date: Thu, 13 Oct 2011 16:44:50 +0200	[thread overview]
Message-ID: <20111013144450.GA2856@victor.terreactive.ch> (raw)
In-Reply-To: <loom.20111013T141239-151@post.gmane.org>

On Thu, Oct 13, 2011 at 12:42:42PM +0000, arQon wrote:
> Simple testcase:
> 
> >git init
> Initialized empty Git repository in C:/git-test/.git/
> >notepad file1
> >notepad file2
> >git st
>  # On branch master
>  # Initial commit
>  # Untracked files:
>  #   (use "git add <file>..." to include in what will be committed)
>  #       file1.txt
>  #       file2.txt
>  nothing added to commit but untracked files present (use "git add" to track)
> 
> >git add .
> >git st
>  # On branch master
>  # Initial commit
>  # Changes to be committed:
>  #       new file:   file1.txt
>  #       new file:   file2.txt
> 
> >git commit -am "init"
>   2 files changed, 2 insertions(+), 0 deletions(-)
>   create mode 100644 file1.txt
>   create mode 100644 file2.txt
> 
> >git co -b foo
>  Switched to a new branch 'foo'
> >notepad file1
> (edit stuff)
> >git st
>  # On branch foo
>  # Changes not staged for commit:
>  #       modified:   file1.txt
> 
> >git co master
>  M       file1.txt
> 
> file1 now has the wrong data in it for "master" branch.

The most important thing a VCS should do is to keep history intact.
That happens when you check out in Git: No branches were changed, only
the working space. The second most important thing a VCS should do is
not destroy any of your uncommitted work unless you tell it to. That
also happens when you check out in Git. The third most important thing a
VCS should do is facilitate the developer's workflow. One common thing
to do is to work on some thing, for example refactoring. During this
process you might realize that one of the changes actually fixed a bug
in the software. To keep things in their right place, you could now
either
1. `checkout master` and commit the fix there, then shift back and
continue working, or
2. commit the refactorings, `checkout master`, and commit the fix there.
Either of these are easy to do with Git. There really is no reason why
the changes in the workspace should be considered as "part of" the
currently active branch, because they *are* not.

Cheers,
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

  parent reply	other threads:[~2011-10-13 14:45 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
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 [this message]
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=20111013144450.GA2856@victor.terreactive.ch \
    --to=victor.engmark@terreactive.ch \
    --cc=arqon@gmx.com \
    --cc=git@vger.kernel.org \
    /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).