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

David Roundy droundy at abridgegame.org
Sat Apr 30 08:34:01 PDT 2005


On Sat, Apr 30, 2005 at 04:51:16PM +0200, Juliusz Chroboczek wrote:
> > But for this to be simple, the *parents* (who don't necesarily
> > themselves have multiple parents) need to be tagged.  Thus my desire to
> > have every git commit treated as a patch+tag.  Each such tag would
> > include in it just the patch itself, and the tags of the parents.
> 
> That I fail to see.  I'll implement my adaptation of your neat scheme,
> and see where it breaks down.

Okay, that sounds like a good plan.  Just because I think I can see how my
scheme would work and can't see how yours would work certainly doesn't mean
it wouldn't work.  ...Parse that one if you can!  :)

> > then we'd have to walk back up (or down?  my trees are usually
> > upside down from everyone else's...) the history
> 
> Trees grow downwards in all CS textbooks except in the German-speaking
> world.  So other than the fact you're not German, there's nothing
> particular about your choice of orientation.

Well, I am something like one fourth or one eighth german (although 100%
non-german-speaking), so perhaps that explains it.  I can't see,
botanically speaking, how a tree with the root at the top would be able to
grow, that would imply that its leaves are underground!  :)

> OTOH, Git's history is a DAG, not a mere tree.  And those you can
> orient any way you see fit.

That's a relief! Because I wasn't at all sure which direction the git
history was growing...

> > failure is fine.
> 
> Sorry, couldn't resist the temptation to quote you out of context.

 :)

> > It would be all right with me if a round trip path
> > darcs-to-git-to-darcs had the net effect of adding a tag to the darcs
> > repository.
> 
> I've currently reformulated my goals: the Darcs/Git correspondence will
> not be an isomorphism, but a retract.  In other words, darcs->git->darcs
> will preserve all information, but git->darcs->git might loose some
> (notably ordering between patches).
>
> The nice property of retracts is that they're idempostent: if you do
> g->d->g->d, you get the same result as if you did g->d.

Indeed, a retract sounds like a good goal.  This loss of patch ordering
would mean that the same darcs patch could show up as two distinct commits
in git, if I understand you right? But when it got back to darcs again, it
would be a single patch?
-- 
David Roundy
http://www.darcs.net




More information about the darcs-devel mailing list