[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git pull fails with merge conflicts. How can this possibly happen?

From: David Kastrup
Subject: Re: git pull fails with merge conflicts. How can this possibly happen?
Date: Mon, 17 Nov 2014 17:54:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> Git, OTOH, could have used the widely adopted terminology and
> semantics, but instead deliberately chose not to.  Doing things better
> doesn't need a drastic change in terminology.

Git was created in order to enable workflows as efficient than those
developed while using BitKeeper whose license for use by Linux
developers had been pulled.

To be on the safe legal side, one design metric was to be quite
different from BitKeeper.  Another design metric was high efficiency.
A prototype was running within weeks, basically consisting of several
low-level commands.  Yet another design metric was to avoid falling into
any of the traps of the current centralized version control systems.

So the idea was to be really different from Bitkeeper (which was
considered a good system but must not be copied) and really different
from established centralized VCS systems (which were considered bad
systems to the degree that Torvalds said something like the SVN slogan
"a better CVS" was sort of an oxymoron since he considered "everything
CVS should have been" would be more or less "dead, buried, and
forgotten").  In practice, I don't feel that the "really different"
angle is all that strong.  Still, when trying to search for pillars one
can rely on, this may prove irritating.

Git was heavily used and developed before anybody could have tried
retrofitting an overarching design and philosophy over what happened to
work efficiently.  Restraining the toolbox the first generation coders
would have met disapproval (of the "changing horses in midstream" kind),
and it would also likely have been considered hubris.

So Git is more or less defined by its mechanisms rather than its
concepts.  Changing that would likely prove tricky.  There are several
toolsets, graphical or command line, facilitating/favoring particular
workflows.  Emacs has its own chance of supporting particular workflows
via what it makes available as part of PVCS and/or VC.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]