Fixing rebase rather than avoiding it

Matthew D. Fuller fullermd at over-yonder.net
Thu Mar 4 10:58:43 GMT 2010


On Thu, Mar 04, 2010 at 09:21:43PM +1300 I heard the voice of
Talden, and lo! it spake thus:
>
> Why do we always seem to divide into groups of extremes

What other outcome is there where there's a disagreement on something
that people with differing opinions care about?

> There must be some middle ground

Middle grounds are often much more wrong than either extreme end.  And
most cases where it's apparently less so, it's because the axis being
examined isn't fundamental.


> One group seems to consider the merged branch-history burdensome and
> would prefer to always remove it. The other group basks in deific
> glee at their tools refusal to allow the editing of the DAG
> (regardless whose DAG it is).

And terminological blurrings only fuel the fires all around.

AFAIK, _NO_ current system lets you edit the DAG.  All you can do is
create a new DAG and direct attention to it[0].  The ability to
actually _edit_ the DAG would lose all sorts of properties that make
the DAG practically advantageous.  And it's basically _impossible_ for
a system to prevent that anyway; in the most basic sense, if it can
create one history in the first place, it can create another one too.

And certainly, the ability to efficiently handle obliterate-ish
functionality is an absolute non-negotiable necessity in a number of
situations.  I don't think anybody would argue against the existence
of such a thing.

The schism isn't between people wanting the ability to create and
switch to a parallel history, and those wanting the ability denied;
it's between people who advocate it as a standard component of an
everyday workflow, and those who reserve it for extraordinary
situations.  It's not really possible to deny that it has costs (it
discards information) and benefits (it creates specific
configurations); but the two parties evaluate the absolute and
relative weights of both VERY differently.




[0] Some will claim that's the same thing.  Usually in that case by
    'DAG' they mean the conceptual global DAG of every revision ever
    entered into the VCS, on any project anywhere in the world, which
    is a huge hodgepodge of many unconnected bits.  In which case you
    apodictically can never "make a new one" because there can never
    be more than one.  In bzr-speak, though, it generally always
    refers to the DAG hanging off a specific head reference.  In the
    most amusing (?) cases, these sort of split meanings can lead to
    long threads of people hotly defending the same position from each
    other.



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.



More information about the bazaar mailing list