Re: Darcs and git: plan of action

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

                                        Juliusz