On 27 Mar 2009 at 18:30, Junio C Hamano wrote:
> "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.
Hi!
OK, that example is not that dangerous in git, but git also has commands a
beginner could make some undesired damage ("git rebase", maybe).
Regards,
Ulrich
--
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
