On Thu, Oct 18, 2012 at 12:59 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, Oct 17, 2012 at 02:58:41PM +0200, Felipe Contreras wrote:
>
>> I've looked at many hg<->git tools and none satisfy me. Too complicated, or too
>> slow, or to difficult to setup, etc.
>
> I run into this every few months, evaluate all of the options, and come
> to the same conclusion. So I am excited at the prospect of something
> simple that just works out of the box.
>
> Unfortunately, when I tried it, it did not work for me. :(
>
> Details below.
>
>> contrib/remote-hd/git-remote-hg | 231 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 231 insertions(+)
>> create mode 100755 contrib/remote-hd/git-remote-hg
>
> Is this "hd" a typo, or is there something clever I am missing?
Yeah, I've fixed that now.
>> --- /dev/null
>> +++ b/contrib/remote-hd/git-remote-hg
>> @@ -0,0 +1,231 @@
>> +#!/usr/bin/python2
>
> I do not have /usr/bin/python2. I do have (on my Debian box):
>
> $ ls -l /usr/bin/python* | perl -lne 'print $& if m{/.*}'
> /usr/bin/python -> python2.7
> /usr/bin/python2.6
> /usr/bin/python2.7
> /usr/bin/python3 -> python3.2
> /usr/bin/python3.2 -> python3.2mu
> /usr/bin/python3.2mu
> /usr/bin/python3mu -> python3.2mu
>
> Obviously a minor, easily fixable issue, but I wonder if it should ship
> with a more portable default (like just "/usr/bin/python", or even
> "/usr/bin/env python").
Yeah, this has always been an issue in Arch Linux; I have to compile
git by exporting PYTHON_PATH.
I'm OK with using any of the two above suggestions above, as they are
more standard.
>> +# Inspired by Rocco Rutte's hg-fast-export
>> +
>> +# Just copy to your ~/bin, or anywhere in your $PATH.
>> +# Then you can clone with:
>> +# hg::file:///path/to/mercurial/repo/
>
> The first thing I tried was:
>
> $ git clone hg::https://code.google.com/p/dactyl/
Right, doesn't look like it works for remote repositories. I think
that's the next feature I want to implement, but to be honest, I don't
think it's a big issue. To replace this:
git clone hg::https://code.google.com/p/dactyl/
With this
hg clone https://code.google.com/p/dactyl/
git clone hg::dactyl dactyl-git
We could do what other tools do, manually clone the repository and
store it internally, but I'll rather not trick the users this way.
> I worked around it by doing an hg-clone and trying to git-clone from
> that local clone. But that didn't work either:
>
> $ hg clone https://code.google.com/p/dactyl/ hg
> [... clone eventually completes ...]
>
> $ git clone hg::$PWD/hg git
> Cloning into 'git'...
> progress revision 99 'pentadactyl-1.0b5-branch' (100/5367)
> [... many more progress updates ...]
> progress revision 6766 'cpg-hack' (1400/1467)
> ERROR: Branch 'default' has more than one head
Yes, this is deliberate, we can't have more than one head per branch in git.
What you should do is go to the mercurial repo, and 'hg merge' (I think).
We could just pick the first head, and warn the user instead.
But at the moment it should fail at this point, I wonder why you get
the errors below.
> error: refs/tags/VIMPERATOR_2_2_b1 does not point to a valid object!
> error: refs/tags/muttator-0.5 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b1 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b2 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b3 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b4 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b4.1 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b4.2 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b4.3 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b5 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b5.1 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b6 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b7 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0b7.1 does not point to a valid object!
> error: refs/tags/pentadactyl-1.0rc1 does not point to a valid object!
> error: refs/tags/vimperator-0.4.1 does not point to a valid object!
> error: refs/tags/vimperator-0.5 does not point to a valid object!
> error: refs/tags/vimperator-0.5-branch-HEAD-merge-1 does not point to a valid object!
> error: refs/tags/vimperator-0.5.1 does not point to a valid object!
> error: refs/tags/vimperator-0.5.2 does not point to a valid object!
> error: refs/tags/vimperator-0.5.3 does not point to a valid object!
> error: refs/tags/vimperator-1.0 does not point to a valid object!
> error: refs/tags/vimperator-1.1 does not point to a valid object!
> error: refs/tags/vimperator-1.2 does not point to a valid object!
> error: refs/tags/vimperator-2.0 does not point to a valid object!
> error: refs/tags/vimperator-2.0a1 does not point to a valid object!
> error: refs/tags/vimperator-2.1 does not point to a valid object!
> error: refs/tags/vimperator-2.2 does not point to a valid object!
> error: refs/tags/vimperator-2.2b1 does not point to a valid object!
> error: refs/tags/xulmus-0.1 does not point to a valid object!
This is weird.
> I seem to remember getting this with other importers, too (probably
> because they were also based on the same script).
hg-fast-import also fails if there are multiple heads, also deliberately.
> We do not need to fix every bug before bringing a script into git
> (especially into contrib/), but I am wondering if this script errs too
> much on the side of "simple" and not enough on "works out of the box".
> Maybe this repo is really complex and unusual, and the multi-heads thing
> is not common enough to worry about. But I feel cloning a remote is the
> first thing most people are going to try, and it doesn't work.
Well, maybe the next time you try the branch will be merged. In
mercurial they even warn you about this when you do 'hg push', so it's
not a good practice that they are doing that in their own repo.
As for remote repos, I don't know what we should be doing at the moment.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html