Re: [BUG] git checkout <branch> allowed with uncommitted changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]