0

I have been working a bit on a project I forked in GitHub. The source project I forked from was originally converted from a Mercurial project at Codeplex.

Now I found out that someone else have been converting the Mercurial project into GitHub, but at a later stage and on top of that added some goodies in git. I would like to fork the other repo instead and replay my commits, since the other repo seems to be active. I also want to update the new repo with new changes in the original Mercurial repo.

So here is the scenario:

My repo: 
hg1->hg2->hg3->my1->my2
               |
               ->my3
hgN is the original Mercurial commits, myN is my git commits.

Other guy:
HG1->HG2->HG3->HG4->HG5->og1->og2
HG1-HG3 are identical to hg1-hg3. Same file tree but with different hash though.
ogN are git commits by that other guy.

What I want:
HG1->HG2->HG3->HG4->HG5->og1->og2
          |
          ->my1->my2
            |
            ->my3

Assuming I have cloned both repos and my changes include some branches, how would I create the merged repo?

What if I my changes was in a single branch. Could I do a simple rebase then?

Holstebroe
  • 4,993
  • 4
  • 29
  • 45
  • Are the histories incompatible? I had the impression that hg to git conversion was deterministic (unlike svn to git one) and therefore independent conversions converted the same hg revisions to the _same_ git revisions. Is it not the case? – Jan Hudec Feb 04 '14 at 09:03
  • apparently the two GitHub repos used different techniques for converting the hg repo. These two git-commits matches the same hg-commit. but have different hash-keys: [repo 1](https://github.com/KevinHoward/Irony/commit/3ec2f63d97ccbae8f34473102f8874e11c3e7add) and [repo 2](https://github.com/Alxandr/Irony/commit/2cde698432976bea19929492629e1fa55400b413) – Holstebroe Feb 04 '14 at 12:11

1 Answers1

0

if i understand you right , you want to create 1 repo from 2 (let it be origin with http://hg_repo.com url and my_repo with http://my_repo.com). You can try in next way:

git clone hg_repo
git remote add my_repo http://my_repo.com
git fetch --all
git checkout HG3
git branch my_new_branch
git cherry-pick my1
git cherry-pick my2
Vlad Nikitin
  • 1,929
  • 15
  • 17
  • Is cherry-picking really the best option? What if my changes were complex with a lot of commits, branches and merges? – Holstebroe Feb 04 '14 at 12:02
  • What I would like is my changes to appear as tree branched out from HG3. – Holstebroe Feb 04 '14 at 12:03
  • http://stackoverflow.com/a/1994491/2842568 this post contains exhaustive answer to your firs comment – Vlad Nikitin Feb 04 '14 at 12:18
  • cherry picking doesn't seem very practical if I want to apply a whole subtree of commits from one repo onto another. – Holstebroe Feb 04 '14 at 12:30
  • in the post i have gave you there are few variants (git rebase --onto for ex.), cherry pick 'range' is one of them. read it carefully, try different, backup your work if not sure, and you will be able to do what you whant – Vlad Nikitin Feb 04 '14 at 12:33
  • I have and idea to merge my2 and m3 from your example, then cherry pick range (`git cherry-pick m1^..m4`). and then delete this merge commit with `git reset` – Vlad Nikitin Feb 04 '14 at 12:41
  • My branching turned out to be a bit tricky, so in the end I did a simple rebase. I "lost" some branches, but those branches were merged into the main change branch, so I only lost the branch history. The problem was that I had based several branched on a commit that was present in the target repo and that commit was not relevant, since it was a roll back commit from the original repo I forked from. Anyway, rebasing was ok for me. – Holstebroe Feb 07 '14 at 09:08