[darcs-devel] Re: A darcs that can pull from git

[Juliusz Chroboczek]

> I'm not sure that allowing different patches with the same "user-visible
> handle" is a worthy goal.  How would the user differentiate between the
> two?

In the same way we currently deal with different patches with the same
name.

However, this won't happen in practice.  The need for additional data
in the patch id is just an additional safety; unless the alien system
munges our data, we'll never see such duplicates.  However, being able
to detect duplicates is necessary -- or else we won't be safe.

>> Because of the mismatch between the Darcs and Git models, I'm making some
>> arbitrary decisions; most notably, when I see a Git commit with multiple
>> parents, I arbitrarily choose one of the parents as ``the'' predecessor
>> of the Darcs patch.

> Argh.  I don't like this at all.  (Switching subjects completely to the
> technicalities of the git-darcs translation.)  Does this mean that you
> aren't encoding the entire tree of the git history? Do both parents end up
> being encoded?

Yes, they both potentially end up being encoded (but not necessarily
in the same Darcs repo -- the two parents might belong to different
branches).  The only issue here is that I need to choose one or the
other of the parents to compute a patch against.

In case that's not clear: there's a Git tree A that has parents B and
C.  In order to encode A as a Darcs patch, I need to either compute
(A-B) or (A-C).  The choice is arbitrary.

> What I've envisioned...

I see -- the tag allows you to avoid the dissymetry.  Neat.

You've convinced me it's a good idea to convert trees with multiple
parents into Darcs tags.  And the performance should not be a problem,
I've yet to see a Git commit with multiple parents.

>> Darcs patch, compute its flattening (merger_equivalent and friends),
>> generate a new patch id -- without changing the user-visible handle
>> --, and push the result.  Of course, if that patch gets pulled back
>> into Darcs you'll get a merge conflict, but what did you expect?

> Here I strongly disagree.  I don't want to lose *any* information when
> passing a change from darcs to git,

That's okay; we can think about that later.  In the short term, I'll
just fail when I see a merger.

> If we knew at record time that we were planning on pushing to git later, we
> could tag after each record, and by pushing those tags we could ensure that
> we never had to push a merger.  I wouldn't mind this constraint on
> git-interoperable repositories.

Yes, that's exactly where we disagree.

                                        Juliusz