Re: On git 1.6 (novice's opinion)

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> > ... Also some seemingly dangerous commands that cannot easily be undone
> > should ask safety questions ("cvs merge (-j)" would also fall into that
> > category.
> 
> This is slightly an interesting point.
> 
> In CVS and Subversion, "merge" (rather "update") can be a dangerous
> operation.  You start working, you keep building, and you eventually
> accumulate quite a lot of changes but you still cannot see the end of the
> tunnel.  Your changes are incomplete and you will upset others if you
> commit.  Your changes are extensive enough that it can conflict heavily
> with what others have done already, and there is a high chance that you
> can screw up the merging but there is no easy way (unless you tar-up the
> whole work tree before attempting to update) to get back to the state
> before your merge.  Damned if you commit, damned if you don't.  You lose
> either way.
> 
> This is because you cannot have a local commit.  The problem is inherent
> to the centralized nature of these systems.
> 
> Distributed systems are different.  Unlike CVS/Subversion's
> 
> 	work work work; then
> 
>         update to merge, risk screwing up the work in progress (or almost
> 	finished work); then
> 
>         commit
> 
> workflow, in a distributed system, you first commit and then merge,
> preferably from a clean slate.  You will not have to worry about screwing
> up the conflict resolution, because both states (what the other guy did,
> and what you did) are committed safely away and you can reset back to the
> state before you start your merge.