2

I am trying to clean up a repository using hg convert --filemap. Convert works fine with any option in filemap except rename. If I add any rename option to filemap then it fails at the first merge with abort: unable to convert merge commit since target parents do not merge cleanly.

I tried putting in filemap only a dummy rename foo bar option (none of the foo or bar paths actually exist in the repo) and I get the same result.

I tried putting in a real rename (existing 1st path), same happens. As fast as any rename gets in there, it breaks.

It this a bug? What am I doing wrong?

UPDATE: To reproduce:

Create file a, write something in it, commit. Update to parent, write something else in a, commit. Merge with other head, fix conflict by hand.

Filemap consists of one line and one line only: rename foo bar. Run hg convert. It will fail if the commit can't be automatically merged.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Dinu
  • 1,374
  • 8
  • 21
  • You have to show at least you filemap, because in my smallest test repo I could use filemap and got converted repo with totally renamed files – Lazy Badger Aug 17 '19 at 13:59
  • @Lazy Badger: Filemap consists of one line and one line only: `rename foo bar` – Dinu Aug 17 '19 at 22:28
  • a) File- directory names must be quoted b) IMHO not-existing objects are useless for testing c) You *have* to show **real sample** (maybe short) of merge-parents, mergeset and failed filemap (and maybe versions of extension and Mercurial) - because my test was successful it can be uncommon error. – Lazy Badger Aug 18 '19 at 10:25
  • JFYI https://stackoverflow.com/questions/44702719/mercurial-convert-error-unable-to-convert-merge-commit – Lazy Badger Aug 18 '19 at 10:33
  • Yeap, it seems that question describes the exact same problem. (And it has the same fix, removing the `rename`. So it's not uncommon and it's 100% reproducible. Create file `a`, write something in it, commit. Update to parent, write something else in `a`, commit. Merge with other head, fix conflict by hand. Run `hg convert` with `rename foo bar`. It will fail. Any rename directive will trigger redoing all merges in a convert. Any rename. All merges. A merge that can't be automatically resolved will fail. Always. Every single time. – Dinu Aug 18 '19 at 21:31

2 Answers2

0

Can't reproduce error with filemap, defined according to extension wiki rules:

Original repo

Repo>hg log --style changelog
2019-08-17  Me

        * file1.dat, file1.txt:
        Merge all from Data1
        [21caf63b7011] [tip] <Data2>

        * file1.dat:
        Compability fix
        [77667c9ad22c] <Data2>

        * file1.dat, file1.txt:
        Mod for Data2
        [7253bf25d7e7] <Data2>

        * file1.dat, file1.txt:
        Mod for Data1
        [de1f80454b7b] <Data1>

        * file1.dat, file1.txt:
        Mod1
        [7f1dd9e27ceb]

        * file1.dat, file1.txt:
        Initial tree
        [d10d46c86e0f]

Converted repo

Conv>hg log --style changelog
2019-08-17  Me

        * core.code, data.dat:
        Merge all from Data1
        [350d1675a713] [tip] <Data2>

        * data.dat:
        Compability fix
        [7b13e52e0887] <Data2>

        * core.code, data.dat:
        Mod for Data2
        [05f2eae8379c] <Data2>

        * core.code, data.dat:
        Mod for Data1
        [6776b7ac4388] <Data1>

        * core.code, data.dat:
        Mod1
        [c733197f909c]

        * core.code, data.dat:
        Initial tree
        [19230ad05c7a]

Filemap

rename "file1.txt" "core.code"
rename "file1.dat" "data.dat"
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Is the merge one that would normally generate a conflict and that was resolved? It looks that the problem is that convert with rename tries to redo merges and fails at the first merge it cannot resolve. – Dinu Aug 17 '19 at 22:27
0

I had the same error and I worked around it by splitting my conversion into multiple steps.

It seems like the problem is when you have a combination of renames in the filemap AND merges in the included history during a single run of convert. So I did this:

  1. Step 1: run hg convert using a filemap with NO RENAMES. Basically just to include/exclude things from the original repository into a temporary intermediate repo.

  2. Step 2: run hg convert again using a filemap that did only renames. This would go from the intermediate to final repositories. Even though merges were still in the history, no problems.

  3. Delete the intermediate repository

This got around the "abort" problem. Also a secondary benefit was that since step 1 was the longest (it was picking only a few 100 changesets out of about 20000) it became much easier to iterate on the renames. I find that filemaps are a little hard to get right since things will just fail silently.

I was using "Mercurial Distributed SCM (version 5.7)"

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81