As part of bug 968958 I'll be importing a number of vcs tools into the new repo, under an appropriately named subdirectory. I'm creating a quick script for this to speed things up, reduce chance for user error & so the next time myself/someone else does something similar, we don't need to figure it all out again. I want to preserve history, but ensure that the new commits are rebased, so there are no detached heads/non-linear changesets (given that the repo being imported shares no common changeset with the target). I'll be taking a similar approach to the one that I used in bug 875323 - with the tweaks mentioned in bug 968958.
Created attachment 8381427 [details] repo-import.sh Example usage: [version-control-tools]$ ~/repo-import.sh ../qbackout hgext/qbackout Import ../qbackout into the subdirectory hgext/qbackout? (y/n)?y pulling from https://hg.mozilla.org/hgcustom/version-control-tools/ searching for changes no changes found pulling from https://bitbucket.org/sfink/qbackout searching for changes no changes found scanning source... sorting... converting... 14 initial version spliced in ['35dd41bb1376910b4273c6d89387f4e53851fc44'] as parents of 753e9529a6a2bcf33847d4d1f2d29bc1adb134d1 13 add examples, pointers to more help 12 It turns out that the default patch format *still* isn't git, so file adds/removes were ignored. 11 Backwards compatibility with hg 1.7.5 10 Implement --apply and --broken arguments 9 pair of stoopid bugs that resulted in not getting bug numbers included 8 cannot index sets, stupid 7 Fix failure when reporting error 6 pyflakes fixes 5 Automatically reuse original commit message when appropriate 4 Patch order is backwards for --apply 3 Bug 894894 - Preserve the original author when using --apply; r=sfink 2 Mercurial likes to blame extensions that don't declare what they've been tested with. r=divineright 1 Add .hgignore; r=sfink 0 Create a README file [version-control-tools]$ hg heads changeset: 250:425819b74190 tag: tip user: 'Nigel Babu <snip>' date: Tue Oct 22 20:57:09 2013 +0530 summary: Create a README file
You may want to consider upstreaming this into the contrib directory of Mercurial or possibly convert it to a simple extension that calls into convert.
(In reply to Gregory Szorc [:gps] from comment #2) > You may want to consider upstreaming this into the contrib directory of > Mercurial or possibly convert it to a simple extension that calls into > convert. Matt, do any of the suggestions above sound like something you may be interested in? :-)
Perhaps not in contrib, but it might want to live on our wiki.