[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] git importer
From: |
Jerome Baum |
Subject: |
[Monotone-devel] git importer |
Date: |
Sun, 12 Jun 2011 15:42:39 +0200 |
Here are my notes from the wiki:
1. git's fast-export format doesn't carry enough branch information, as
monotone's branch model is much more information-rich than git's --
ignoring reflogs for a moment, which aren't used by git-fast-export and
aren't synced between git repos. In principle the fast-export format
could carry the information, but it doesn't. reflogs may also not be
available everywhere, so we'll just have to accept that git is "lossy"
and find a best solution.
2. The fast-export format doesn't carry unique identifiers per commit, so it
might make more sense to import directly from the git repo. We loose
flexibility (e.g. hg --> mtn would have to go through git), but can carry
over more information (think x-git-commit-id certs).
3. On the other hand, we shouldn't need to worry about duplicate commits as
the exporter should track that.
4. Just ran another test with git-fast-export. Turns out you can't export a
subset of a branch (say, the latest commits). Well, you can, but try
exporting just the tip of your branch: You'll end up with a single commit
that adds all your files. Basically git-fast-export always assumes the
first commit to come out of nothing, even if it really doesn't.
a. Based on this, we really can't work with the fast-export format for
partial imports, and partial imports would be really nice to have. So
here's plan B: import directly from git.
In summary, git's internal branch model doesn't retain enough information --
save for reflogs -- so obviously the fast-export format won't exactly be
more informative. We can take advantage of reflogs if we import directly
from the repo. As fast-export doesn't support partial exports anyway, this
looks like the best solution.
I'm thinking of using the plumbing interrogation commands for this. Makes it
much easier than parsing the repo files, and probably easier to adjust later
on if we want to support another VCS.
For branch name mapping, I'm thinking of just using some DB variables or a
simple config file -- the DB variables being preferable for the sake of
partial imports on a regular basis. This is how a first version would work
anyway, and we can improve the UI once we have a working prototype.
Now, I saw the net.venge.monotone.git branch but that looks pretty old and
outdated. I have locally created net.venge.monotone.vsync to start my work.
Happy for any input.
--
Jerome Baum
tel +49-1578-8434336
email address@hidden
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
- [Monotone-devel] git importer,
Jerome Baum <=