Re: On git 1.6 (novice's opinion)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 28, 2009, 01:30 UTC
Message-ID: <7veiwi5t8j.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>

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