Re: Darcs and git: plan of action

From: Juliusz Chroboczek <juliusz.chroboczek@pps.jussieu.fr>
Date: Apr 19, 2005, 00:55 UTC
Message-ID: <7iy8bf7fh2.fsf@lanthane.pps.jussieu.fr>
In-Reply-To: <20050418122011.GA13769@abridgegame.org>

[Using git as a backend for Darcs.]

> The problem I have with this is that "other" repository formats (e.g. git)
> store "tree versions", not "changes", and I think it would be fragile to
> try to store "changes" (in the darcs sense) in them.

Not really; a Darcs patch is just a pair of two git versions (from and to). Which is why Darcs needs to support arbitrarily formatted patch ids -- a patch originating from git will be identified by a pair of git hashes.

Obviously, we'll need to think harder when pushing from darcs into git (we'll need to preserve the Darcs patch id somehow), but it's premature to worry about that right now.

>>  1. remove the assumption that patch IDs have a fixed format.  Patch
>>     IDs should be opaque blobs of binary data that Darcs only compares
>>     for equality.

> I'm not really comfortable with this,

Why?

Show 8 quoted lines

>>  3. allow a patch to have multiple IDs; if the IDs associated to two
>>     patches are not disjoint, then the patches are the same patch.
>
> This I find a bit confusing.  So a patch can have two IDs, presumably
> something like a "darcs ID" and a "git ID"? I can see that this might
> simplify some things, but am not sure how it would work.  The IDs would
> have to have a hierarchy, so that you wouldn't ever end up with the "same"
> patch having disjoint IDs in two cases.

It's a case of ``don't do that''.

Suppose I record a patch in Darcs; it gets a Darcs id. I push it into git, at which point it gets a git id, whether we want it to or not. What do we do when we pull that patch back into darcs?

Either we arbitrarily discard one of the ids (which one?), or we keep both. If there's more pulling/pushing going on on the git side, we definitely need to keep both.

> Here's where I think I'd differ.

Same to you ;-)

> I think when dealing with git (and probably also with *any* other
> SCM (arch being a possible exception), we need to consider the
> exchange medium to be not a patch, but a tag.

We're thinking in opposite directions -- you're thinking of the alien versions as integrals of Darcs patches, I'm thinking of Darcs patches as derivatives of alien versions.

  You:  alien version = Darcs tag

  Me:   Darcs patch = pair of successive alien versions

My gut instinct is that the second model can be made to work almost seamlessly, unlike the first one. But that's just a guess.

> if we want long-term stability we might need to mummify a variant of
> the diff algorithm that we agree not to change,

Good point, noted.

> But avoiding "mv" patches would be downright silly.

Aye, that will require some metadata on the git side (the hack, suggested by Linus, of using git hashes to notice moves won't work). Happily, it's premature to worry about that, too.

                                        Juliusz