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 http://www.darcs.net - 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
