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

[Holger Hellmuth <hellmuth@ira.uka.de>]

On 13.10.2011 15:58, arQon wrote:
> Andreas Ericsson<ae<at>  op5.se>  writes:
>> there's no reason to refuse the branch change.
>> Partly because nothing will be lost
>
> Actually, this isn't true either, because of the second bug: doing a revert
> in branchA causes the changes in branchB to be lost. This can't possibly be
> the intended behavior: again, it completely violates the integrity of branches
> by allowing changes on one branch to impact a different branch.

I assume you mean revert through 'git checkout' and not through 'git 
revert'. Git uses a different philosphy. It works best with small 
commits and commits done often. It assumes that when you switch 
branches, you don't switch your brain as well and still know for what 
purpose you changed tr_font.cpp (and even if you forget you always can 
check with git diff).
It also reminds you that tr_font.cpp is changed when you switch branches 
(remember the "M tr_font.cpp" printed when you switched to another branch).
It assumes that when you use 'git checkout --' to wipe out changed files 
without committing them anywhere(!) that you have thought about it the 
same way you have thought about before deleting or overwriting any file 
in the file system. The same way you have thought about before deleting 
or overwriting an uncommitted file in svn.

What you term integrity of the branch is a model you made of the 
workings of svn that you now try to pin onto a different model.