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