[darcs-users] Darcs in kernel-like development model

[Stephen J. Turnbull]

John Goerzen writes:

 > So my understanding of how rebase works is that you take all the
 > patches since the last upstream release from one branch and apply
 > them on the other branch.  People that are tracking your repo will
 > be following branch A (let's call that your original local branch).
 > Now you have created branch B with your rebase, and never will
 > merge.  In Hg lingo, you now have two heads.

Right.[1]  So let's rephrase your statements in Mercurial language.  A
branch is a named branch, while a head is the tip of an implicit
branch.  You created a ref "branch A" to "head A", then moved that ref
to "head B".

 > So what will Joe Random Developer do now?  He will somehow have to
 > switch from your branch A to your branch B.  This will not be
 > automated, because how is his VCS to know what branch becomes your new
 > canonical one?

It's actually very simple, I think.  Just fetch (in git terms, that
includes all objects needed to fill out the branch), then move your
local ref of A to whatever that head is.

If he has local changes, he keeps them as local changes, and does a
git rebase before fetching the new referent of A.  Then he rebases
from the head A used to refer to to the head A now refers to.  (This
is just Arch's update strategy, really: local patches *always* on
top.)

Just like quilt or MQ.  Of course it requires discipline, but it
probably can be substantially automated.

 > What's worse, the only common ancestor is the very first upstream
 > version pulled in.

This is a solved problem, at least in git.  You just trace the
ancestor chains until you run into a commit that's in your object
database, and then download everything in the trace.

 > Git and Mercurial users will tend to ignore it in the
 > rebase/transplant scenario, but yes, it still exists -- though in a
 > not terribly convenient form, after a rebase.

But it's easy to maintain convenience with a tag.

 > > it's not clear to me from following darcs-devel with its two-line
 > > patches followed by 2000 lines of dependencies that in practice the
 > > notion of dependency actually used isn't pragmatically equivalent to
 > > ancestry.)
 > 
 > I have never really grokked how Darcs dependencies are calculated.
 > But I have suspected this myself at times.
 > 
 > > > features, it does not have a way to arbitrarily merge two patches
 > > > back in the history -- at least not a convenient way.
 > >
 > > Worse yet, Darcs is ahistoric.  That's what it means to say that there
 > > is no complete ancestry DAG.
 > >
 > > But I don't understand what you're asking for here.  Specifically,
 > > what's missing from "patch < PATCH-A && patch < PATCH-B && darcs
 > > record"?
 > 
 > Well, first you'd have to darcs diff -u to get the two patches, then
 > commit a patch undoing them, then this one, and you still have the
 > "ugliness" in your history.
 > 
 > > >  * Loss of development history due to having to throw out old branches
 > >
 > > This is a common misconception about how rebase works.  No history is
 > 
 > What about the commands that let you combine two separate git patches
 > into one?

(I have to say I'm really sorry to be writing so much about git, but
git is what I understand how to analyze.)

There's no concept of "git patch" AFAIK.  You can do something like
take a tree that looks like

    A <- B <- C = branch
    |    |    |
    a    b    c

and via "git reset HEAD~2; git commit" make it look like this

    A <- C' = branch
    |    |
    a    c

where uppercase letters name commits, lowercase letters name trees,
and words name refs.  Note that because parent(C') != parent(C),
C' != C, even though the trees are the same.  But what the repo looks
like is

        +---- C'
       /      |
  a   /  b    c
   \ L   |    |
    A <- B <- C = branch

and it is trivial to turn that into

        +---- C' = tag
       /      |
  a   /  b    c
   \ L   |    |
    A <- B <- C = branch

if you plan ahead, and not all that much harder if you don't (use
git-fsck).

The problem I face in trying to apply that to Darcs is that I don't
know how to draw equivalent pictures for Darcs.

Footnotes: 
[1]  Actually, you can apply a rebase on top of an arbitrary commit in
git; I don't know about Mercurial because of its linear repo format.