[darcs-users] seamless git integration

[Stephen J. Turnbull]

Petr Rockai writes:
 > "Stephen J. Turnbull" <stephen at xemacs.org> writes:
 > 
 > > Indeed.  A standard hunk darcs-patch can be expressed efficiently
 > > (enough, in smallish repos) as a pair of git-tree objects.
 > 
 > Unfortunately, this is not completely true. This only works as long
 > as you freeze the diffing algorithm.

Why do you need to freeze the diffing algorithm?  Each instance of
darcs uses the diffing algorithm it uses.  Where's the problem?  It's
only a problem if you are passing around diffs themselves; the point
is that you're not.

 > > However, for doing darcsy stuff, you'd really want the patches
 > > themselves.  Interestingly enough, in a packed format repo,
 > > *most* versions are represented as patches IIUC.
 > 
 > As binary deltas. But these are unrelated to actual history. It is
 > just a compression heuristic.

So what?  This is just a source of hunks.  And of course they're
related to actual history: they'd be useless without an index saying
"to build tree 281 from tree 267, use hunks A, B, ... Z."  You get the
tree IDs from the commits you're working with.  Agreed, you may have
issues here wrt to the differ, but it's not clear to me that they're
as subtle as you say.  Of course you'd need to convert to darcs
internal format, but patch(1) seems to do fine with multiple, very
different formats.

In debug versions, of course you'd build in a sledgehammer check:
every patch "efficiently" extracted from a pack would be compared with
the darcs diff based on the actual trees constructed from the git
repo.