Re: [BUG] git checkout <branch> allowed with uncommitted changes
- From
- Holger Hellmuth <hellmuth@ira.uka.de>
- Date
- Oct 13, 2011, 16:08 UTC
- Message-ID
- <4E970CEC.3000509@ira.uka.de>
- In-Reply-To
- <loom.20111013T152144-60@post.gmane.org>
On 13.10.2011 15:58, arQon wrote:
Show 8 quoted lines
> 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.