[RFC] Importing from a patch-oriented SCM

[Martin Langhoff <martin.langhoff@gmail.com>]

I am drafting an import script to turn a GNU Arch into a GIT archive.
Importing the branches and commits increamentally is reasonably
straightforward -- or so it seems so far. Note: the repository
manipulation is based on cvsimport -- so my knowledge of the git repo
internals is still pertty close to zero.

Each patchset has a unique identifier, and can carry metadata with the
identifiers of the patches it "includes". If you are using gnu arch,
when you merge across branches, it'll know to skip a particular
patchset if it has been applied already. AFAICT there is no such
concept in GIT, and I wonder what to do with all this metadata about
merges.

My proto-plan is to keep track of merged stuff (in a cache file
somewhere), and if a particular merge means that the branches are
fully merged up to the last patch of the series (if no commits from
the source branch have been skipped) mark it as a merge in GIT.

If the merges have been done out-of-order, that may show up in the
latest merge. For example, branch A and B of the same project each
have 10 commits from the branching point. If a merge A -> B does
commits 1,2,3,7,8 it gets imported to git as a merge up to commit "3",
although there is more there. The next merge, which does 4,5,6,10 will
show up as a merge of commit 8.

Yuk. 

If I remember correctly, Junio added some stuff in the merge & rebase
code that will identify if a particular patch has been seen and
applied, and skip it even if it's a bit out of order. But I don't know
what that is based on, and whether I can somehow maximize the chances
of the patch being identified as already merged across branches. If
it's based on the initial commit identifier being carried through
(does that travel with commits when you merge?) I stand a small
chance. Otherwise, I'm lost.

Suggestions? 

cheers,


martin