[darcs-users] Fwd: Darcs Problems

[Stephen J. Turnbull]

John Lato writes:

 > Really?  I thought you endorsed the approach of pulling patches without
 > getting their dependencies when somebody else suggested it.  Apologies, I
 > must have gotten some wires crossed.

No crossed wires.  I certainly do endorse "no-dependencies cherry-
picking that still somehow maintains patch identity".  If I didn't, I
wouldn't be in this conversation. :-)

What I don't think is going to work well is having Darcs guess
anything less than "the whole repo" when the user requests the
dependencies (OK, you can leave out patches that come with their own
inverses ;-).

 > Every git commit points to a complete tree in that sense, but that
 > doesn't mean that everything in "some-branch" will exist in
 > "some-rebased-branch".  [Eg] git rebase --onto A B thisBranch

Ah, sure, you can do that with rebase.  But in best practice --onto
can generally be avoided.  IME, the usual application of rebase is
linearizing a "bushy" DAG (<z=Z> indicates a branch head and name):

      B - <x=C>
     /                git rebase x y
    A - D - <y=E>

giving A - B - C <x> - D' - E' <y>.  This doesn't have that problem
(although required features might have been removed in B or C, but
that would be a problem for Darcs too AFAICS).  Of course, any time
you use --onto you're asking for trouble.  But git has two major
advantages over Darcs here, as far as I can see.

(1) In the best practice case, git computes the common ancestor of x
    and y.  In Darcs-with-base-patches, the user needs to apply the
    base patch themselves, and Darcs doesn't warn you about it (how
    could it?) or provide a way to put a base patch in an arbitrary
    place.  The latter probably could be fixed but I don't see how
    offhand and the UI might be problematic.

(2) In git with --onto, if you screw up, you can recover <y> = E (not
    E') from the reflog, and redo the rebase.  In a patch-based VCS
    like Darcs, I don't see any easy way to rewind changes that way.

 > After all, that's what git-rebase is for: changing history!

Not really.  In git, it is impossible to change history (because every
possible history already exists as a SHA1).  What you can change is
the mapping of branch names to histories.  Yes, it's inconvenient to
refer to histories by SHA1, but that's what reflog is for.

 > But if darcs supported a pull-without-dependencies, then at least
 > if you have the same series of commits and manually-specified
 > dependencies darcs could warn you that it won't work and will
 > require manual fixup.

I think it's really optimistic to hope for complete and correct manual
dependencies, or anything even close.  Maybe you personally do better
than me, but in theory since Darcs already computes "too many"
dependencies, I would suspect most users would avoid adding more.

 > You think users will find this unreliable.  I think users will quickly
 > adapt to it,

It would be nice to do an empirical test. :-)

 > >  > In the end, it would be up to the user to make sure that everything
 > >  > is recorded properly, and in particular to code up a suitable
 > >  > replacement for the not-present patch(es) B.  If the user decides
 > >  > in the end it would be easier to get all the dependencies too,
 > >  > that's their own decision.
 > >
 > > Yes.  I believe that even you will quickly come to the conclusion that
 > > it's not worth it: just clone the repo and be safe.
 > 
 > You mean darcs clone ~/repoA ~/repoC; diff -c -r ~/repoA ~/repoB | patch -d
 > -p1 ~/repoC (or something like that), then fix up repoC and, assuming repoB
 > has a number of small, atomic commits re-record them all again?

No.  I mean a slight improvement over current Darcs where

(1) You select a patch to cherry-pick.
(2) Darcs offers to semi-automatically resolve conflicts by
    interactively applying dependences (hunk by hunk[1] as in record),
    then recording the applied hunks as a patch (hopefully with some
    kind of pointer to the original prerequisite patch), allowing you
    to edit the name (a unique name would be automatically generated
    from the original) and log message if you want to.  Lather, rinse,
    repeat until the cherry-pick applies without conflict or you run
    out of dependencies.
(3) Darcs merges the cherry-pick.
(4) Finally, you record the resolution.

but Darcs doesn't try to automatically guess what you need at step 2.
I think this is close to what Ben Franksen had in mind.

Steve

Footnotes: 
[1]  A convenient UI for the "many hunks" case is left as an exercise
for the reader.  Urk!