3

I have a 4 versions of a project. Versions 1-3 were "prototypes" that were originally not under source control (they exist as separate directories in the filesystem). Version 4 has been under source control since inception and now has a long history of commits.

I want to combine these so that versions 1-3 become individual changesets where each one is the descendant of the previous. The root of version 4 should become the descendant of version 3 (and no collapsing of version 4's history of course).

All changes are private, not public (there is no problem with rewriting history, as it were).

What I've done so far and tried:
1. I setup new hg repositories in the directory of the prototype versions
2. I cloned the repository of version 4
3. I pulled (with hg pull --force) the unrelated repositories for versions 1-3 into the cloned repository.

This gives me 4 unrelated "roots" (changesets with no ancestors) in a single repository. When I combine them I don't want to remember these 4 roots. hg rebase should let me move changesets and destroy the originals, unlike hg merge.

Here I'll use 101 as the revision for "version 1" (which is a single changeset with no parent) and 102 as the revision for "version 2".

Attempt 1: I try hg rebase -b 102 -d 101 but get the respone nothing to rebase. Presumably this is because they have no common ancestor (I feel like this is inconsistent... -b 102 would include all ancestors except the common ancestor, which would be nothing in this case.)

Attempt 2: I try hg rebase -s 102 -d 101. This results in merge conflicts. I do hg revert --all --rev 102 and hg resolve -m to indicate that I prefer "version 2" in all conflicts (although I wonder if that is really the right way to prefer one parent over another in the presence of adds/removes?). But when I commit, I don't have a linear history --- revision 102 is still there!

Ein
  • 1,553
  • 3
  • 15
  • 22
  • Possible duplicate of [Join two Mercurial repositories into one line of revisions](https://stackoverflow.com/questions/5859263/join-two-mercurial-repositories-into-one-line-of-revisions) – StayOnTarget Mar 01 '19 at 12:24

3 Answers3

2

If I do hg rebase --continue as the final command (instead of hg commit) then it works perfectly.

I didn't read the last part of the documentation:
http://www.selenic.com/mercurial/hg.1.html#rebase

Ein
  • 1,553
  • 3
  • 15
  • 22
  • If you have merge conflicts while doing merge, rebase or graft you should resolve these manually before marking them as resolved. Otherwise you have inconsistent changesets. – Thomas Jung May 20 '13 at 08:32
  • In my case, `hg revert --all --rev 102` was how I wanted to resolve the conflicts "manually" – Ein May 20 '13 at 12:00
  • @Ein, what was the specific part of the "last part of the documentation" that was the important key to solving this for you? Thanks – StayOnTarget Jun 29 '16 at 18:10
1

As I know, it's better to use --tool "internal:other" on rebasing instead of reverting to a revision.

iuzuz
  • 69
  • 6
0

An alternative to rebase which has worked for me is to use the hg convert extension and --splicemap option.

Although convert is intended to actually migrate from other source control systems (such as SVN) it can also "convert" from hg to hg.

The `--splicemap`` option allows you to explicitly set the child / parent relationship between changesets. I have used this to eliminate branches which originated from unrelated repositories. Mercurial appears to handle this well, e.g., files with the same name appear to have continuous history following the convert/splicemap operation.

I'm not sure if this is necessarily a "better" solution than rebase. It may be more of a niche approach for odd cases (?). One clear downside is that for large repositories the convert procedure can take quite a while to run.

Splicemap documentation.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81