CODEWITHSUNDEEP
gitmercurialhg-git
Nanhydrin
Nanhydrin

Reputation: 4472

Pull to Hg repo from Git repo that is the same project but has lost the history

My scenario is as follows.

The project I have cloned from was originally versioned using Mercurial and I have a clone of that original repo with all it's history. At a certain point in time the owner of the project decided to move to GitHub but has lost all the history in the move so this new repo, although it's a continuation of the old project, is effectively starting anew from revision 0.

I want to stick with Hg, and Hg-Git will obviously allow me to pull from the Git repo, but what I don't know how to do is to stick together the head of the Hg repo with the tail of the Git repo so I can just carry on pulling down regular updates as before. The actual commit in Git that matches the head of the Hg repo is not the first commit, so it's not the tip of the tail.

I thought that hg convert and --splicemap might be useful, but the more I've read about it the less it looks like a solution for me.

Can anyone offer any suggestions as to how I can achieve this?

Update
Just for the information of anyone who might be trying to do something similar, I finally managed to achieve the result I wanted but it was a long and winding road, and it turns out that hg convert and splicemap was the answer after all.

  1. I pulled down the Git repo from Github with the hg-git plugin.
  2. Then I cloned that to a new repo and pulled in the related but disconnected Hg repo contents using hg pull --force.
    So now I have a repo with 2 distinct branches of development which have no common ancestor as far as the repo is concerned, I'm going to refer to this as the hydra.
  3. Using hg convert and splicemap I joined the branches at the matching point in the history into a new repo, and then ran hg strip to get rid of the stray unnecessary bits.
  4. The trick however was that the original Git repo will be updated and I wanted to be able to pull in the new changes to this joined up repo.
    The solution? Batch files.
    Yeah you heard right, batch files.
    The solution was effectively a set of 3, first to pull from Github to the repo that just holds the Git repo. Second pulled from the Git repo into the hydra (the Hg source isn't going to change so I don't need to pull from that again). Third re-ran the hg convert command so that it updates the joined repo with the new information from the hydra.

It's unpleasant, it's long winded and it was a bit of a nightmare to set up, but it works cleanly now and my final repo is a predictable and reasonable size.

Upvotes: 3

Views: 347

Answers (1)

Face
Face

Reputation: 511

Never tried this, but maybe manipulating the git-mapfile in /.hg of the bridge-repo could work. I'd try it like so:

  1. Lets say Hg repo's tip is Git repo's root.
  2. Clone the Git repo via hg-git only up to the root (that's possible with Git, right?).
  3. Pull all the commits from the original Hg repo into the hg-git clone.
  4. Strip away the lone root, but note down the full hash of this root.
  5. Note down the full hash of the Hg repo's tip (also the tip of the hg-git clone now).
  6. Edit /.hg/git-mapfile. It should only contain one entry with the lone root's hash on one side (should be on the right). Replace this hash with the one of the tip. Do not replace the other side (left), as it is the hash of the corresponding Git commit object.
  7. "hg pull". If the theory holds, this will add the new Git nodes onto the old Hg nodes.

Could be complete nonsense, but at least the older ("dumber") versions of hg-git simply determined necessary git objects via this map file. So it would be worth a try...

Upvotes: 3

Related Questions