[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
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,
>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html