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

John Goerzen jgoerzen at complete.org
Wed Feb 6 02:41:11 UTC 2008


On 2008-02-06, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Note that rebase (and I would guess "transplant" -- why do the
> Mercurial people insist on breaking the common idiom so often?) are

Heh, I think that DVCSs are new enough that *all* of them have broken
the common idiom regularly.

> I'm not sure what you're saying next.  A slight gloss makes clear what
> I think it is:
>
> > So if we [try to] model this workflow on a DVCS like Mercurial or
> > Git [without transplant/rebase], here's what we wind up with. [...]
> > You have a complete history, but not a final, complete patch of
> > each logical feature.  That model doesn't work [in the Linux kernel
> > workflow].
>
> Is that OK?

Yes.

> Well put.  But you forget that "presumably" later.
>
> > Now, this model works well for private repos.  In both git and hg, it
> > is difficult to use -- though not impossible -- if you are sharing
> > repos with others.
>
> Actually, it's not difficult at all (in principle!)  It just requires
> a bit of discipline about which branches you expose and how.  Much of
> this discipline can be automated (I haven't done so yet, though I
> suspect that many lkml denizens have; cf. comments about reflog,
> below).

That has me confused, and pardon my butchering of git jargon; I'll use
Mercurial here because I grok it...

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.

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?  What's worse, the only common ancestor is the very
first upstream version pulled in.  

> > That seems similar to using amend-record in darcs.
>
> Maybe.  But amend-record actually destroys history, whereas the only
> command in git and Mercurial combined that does so is git-gc.

That is a fair point; I used "throw away history" too loosely.

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.

> 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?

-- John



More information about the darcs-users mailing list