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