[darcs-users] Questions about darcs (esp. branching)

Stephen J. Turnbull stephen at xemacs.org
Tue Nov 23 04:43:13 UTC 2010


Miles Gould writes:

 > Hence, a darcs user looks at git and says "Git doesn't support
 > dependency-aware cherry-picking, how useless; why should I care
 > about easy branching?", and a git user looks at darcs and says
 > "Darcs doesn't support easy branching, how useless; why should I
 > care about cherry-picking?". But to say that "git doesn't support
 > real cherry-picking"

"Dependency-aware" isn't really the problem.  I often use ephemeral
branches for things like collecting small bug-fixes (eg, output
formatting).  Almost by definition these can't involve dependencies.
The point of using a new branch is to ensure that these changes are
recorded in the context where they were created (which queues/quilts
can't do), and without either creating merge conflicts or cluttering
up semantic changes with irrelevancy.  But Darcs does that
automatically, and you can cherrypick those patches into as many
branches as you like without creating merge issues for later.

So when I write "real cherry-picking" I mean tracking that fact that a
patch was applied to avoid spurious conflicts when merging branches,
not the issue of pulling dependencies with it.  I think that's what
most people mean by "real" cherry-picking, but YMMV.  Since as you
point out neither git nor darcs can automatically provide "precise
dependencies" (whatever that actually means), the practical issue with
cherry-picking is not tracking dependency in general, but tracking
dependency on the cherry-picked patch itself.  Git doesn't do that at
all, unless you put the patch (and any dependencies you want) on a
separate branch.

 > I think of it as optimistic versus pessimistic dependency-tracking:

I like that distinction.  It's great for explaining to patch-oriented
thinking, which is the way most developers think.  (The alternative is
revision-oriented thinking, in which instead of *inventing* patches
and *adding* them to the project history, you *discover* revisions,
and *record* their position in the history.  Revision-oriented
thinking is much more adapted to the way git actually works, but it's
unnatural.)

BTW, as you guessed, "darcs commit --ask-deps" allows you to add patch
dependencies to record semantic dependencies that are not signaled by
textual conflicts.

 > [BTW: the "retroactively branch + cherry-pick" thing works fine in git
 > too,

I'm not sure what you mean by "retroactively branch" in git.  But for
the interpretations I've come up with, I don't think it "works fine".
In all of those it will result in spurious conflicts when merging the
branches, which in not so extreme cases makes them unmergable.

 > All of those ideas sound extremely similar to git's unpacked repo
 > format.

Only at a very high level of abstraction where everything is a blob.

For example, Git's packed repo format uses delta compression, but you
can't directly name and extract those deltas.  You need to extract two
revisions and diff them.  On the contrary, in Darcs you will be able
to extract a patch by name.  But you can't (in general) extract a
revision by name; you need to extract a base revision, and apply
patches to it.

BTW, "unpacked repo format" is a red herring.  It's not semantically
different from the packed repo.  It's just that the packed format is,
well, packed.  That just means that you can't inspect the structure
without git.


More information about the darcs-users mailing list