On Tue, Apr 19, 2005 at 02:55:05AM +0200, Juliusz Chroboczek wrote:
> [Using git as a backend for Darcs.]
> >>  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?

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.  Just seems
dangerous and complicated, and I'm not sure why we'd need to do it.

> 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.

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

> > 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.

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.  How do you define that change?  It's easy
enough to do if we tag each git version in darcs, since we know what the
two parents are, and we know what the final state is, but there *is* no
translation from a single git ID either to a single patch(1) patch, or to a
single darcs patch--unless you treat its parents as tags.

The key is that we can't make git work like darcs, so we'll have to make
darcs work like git.  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.

To summarize how I'd see the mapping between git information and darcs, a
git commit would be composed of one darcs patch and one darcs tag.  With
this mapping, I don't believe we lose any information, and I believe we'll
be able to (except that patches would have to be uniquely determined by a
pair of trees) simply translate the darcs system right back again, since
it's a one-to-one correspondence of information.

My proposed mapping:

tree 6ff0e9f3d131bd110d32829f0b14f07da8313c45
# This is a darcs tag ID
parent abd62b9caee377595a9bf75f363328c82a38f86e
# This is the context of both a patch and tag.
author James Bottomley <[EMAIL PROTECTED]> 1113879319 -0700
# This is the author and date of the patch
committer Linus Torvalds <[EMAIL PROTECTED](none)> 1113879319 -0700
# This is the author and date of the tag
# Everything below would be the name and long comment of the patch

[PATCH] SCSI trees, merges and git status

Doing the latest SCSI merge exposed two bugs in your merge script:

1) It doesn't like a completely new directory (the misc tree contains a
   new drivers/scsi/lpfc)
2) the merge testing logic is wrong.  You only want to exit 1 if the
   merge fails. 

David Roundy
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

Reply via email to