"Ulrich Windl" <ulrich.windl@xxxxxxxxxxxxxxxxxxxx> 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.
--
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
