Re: Darcs and git: plan of action

From: Juliusz Chroboczek <juliusz.chroboczek@pps.jussieu.fr>
Date: Apr 19, 2005, 12:20 UTC
Message-ID: <7i4qe3x8ig.fsf@lanthane.pps.jussieu.fr>
In-Reply-To: <20050419110407.GB28269@abridgegame.org>

[Removing Linus from CC, keeping the Git list -- or should we remove it?]

> I'm not clear why it would be necesary, and it takes the only immutable
> piece of information regarding a patch, and makes it variable.

Er... I'm not suggesting to make it variable, just to make it an opaque blob of bytes (still immutable). I see from the examples you give below that you agree that the format needs extending, so I suspect we're actually agreeing here, just failing to communicate.

about having multiple ids per patch:

> Or alternatively, we could have a one-to-one mapping between git IDs and
> darcs IDs, which is what I'd do.

Okay, you've convinced me. It's much simpler that way, we'll see how well it works.

> The problem is that there is no sequence of alien versions that one can
> differentiate.  Git has a branched history, with each version that follows
> a merge having multiple parents.

Yep. I've just realised that this morning. Is there some notion of ``primary parent'' as in Arch? Can a changeset have 0 parents?

> If we do it right (automatically tagging like crazy people), darcs
> users between themselves can cherry-pick all they like, without
> introducing inconsistencies or losing interoperability with git.

You've lost me here. How can you cherry-pick if every tag depends on the preceding patches? Or are you thinking of pulling just the patch and not the tag -- in that case, what happens when you push to git a Darcs patch that depends on a patch that originated with git?

I've started interfacing Haskell with git this week-end, that's something we'll need whichever model we choose. We should be able to start playing with actually modifying Darcs after next week-end.

                                        Juliusz