Cloning local repos does not work when Mercurial extensions are enabled about git

[felipec]

Works fine here:

hg init test
cd test
echo one >> content
hg add content
hg commit -m one
cd ..
git clone hg::$PWD/test test-git

[dusty-phillips]

Using that exact sequence I get the same "No such file or directory" error. The test-git directory doesn't get created at all, which explains the IOError. I will poke around at it this weekend, but if you have any suggestions for tracking down the problem, I'd be glad to hear them.

Any chance the hg version (2.4.1) is at fault here?

[felipec]

I also have hg 2.4.1.

[dusty-phillips]

@felipec Can you give me any debugging tips or advice? When I try to add print statements or pdb breakpoints to git-remote-hg, I don't get any output. It looks like whatever internals in git that call git-remote-hg are suppressing both stderr and stdout from git-remote-hg. How can I work around that? Is there an option to pass to git to tell it to show git-remote-hg output (I tried -v, no luck), or do I have to compile git with a debug flag set or something?

Edit: no worries, I found the 'warn' method, and wrote a parallel log() method.

[dusty-phillips]

Can you explain why you treat local repos differently from remote ones in get_repo:

    if hg.islocal(url):
        repo = hg.repository(myui, url)
    else:
        local_path = os.path.join(dirname, 'clone')
        if not os.path.exists(local_path):
            peer, dstpeer = hg.clone(myui, {}, url, local_path, update=False, pull=True)
            repo = dstpeer.local()
        else:
            repo = hg.repository(myui, local_path)
            peer = hg.peer(myui, {}, url)
            repo.pull(peer, heads=None, force=True)

    return repo

It looks like if someone clones a local repo, you try to operate directly inside of that repo instead of cloning it to a repo inside .git. I don't get the reasoning behind this; it makes sense to me that no matter where you clone from, you would want a local copy that is fully under your control.

If I take out the if statement and always create the local clone in .git/hg/origin, then everything works correctly for me. However, the git tests fail, so I fear I may be misunderstanding something.

[felipec]

@buchuki Output to stderr is not omitted; that's how I debug.

Why would you want a second copy of a local repository? That means that you would have two mercurial repos, and a git repo. The second mercurial repo is unnecessary, because either way when you push, you want to push to the original one, and when you fetch, you fetch from the original one.

[dusty-phillips]

I can come up with several reasons to want a second copy:

1. It work for me. Trying to interact with the original repo does not. This is a good enough reason for me.
2. A clone of a repository is not identical to the upstream repository (diff shows me a few differences)
3. It lacks symmetry, as compared to the remote cases.
4. Because we don't know how the upstream repo is being utilized, we can't be certain it's state will be properly maintained.

I think at the least, the decision as to whether to make a local copy or operate directly on the local repository should be a configuration time option. I'm willing to supply this patch if you'll agree to merge it?

However, I'm more concerned about solving my original problem. I have managed to do this by deleting my ~/.hgrc. I did some experimenting and discovered that if I enable any one or more of these extensions, git clone hg::/local/repo fails with the error at the beginning of this issue report:

• color
• record
• rebase
• hgk
• hgshelve
• mq
• graphlog
• crecord

IF all of these extensions are disabled in my ~/.hgrc, THEN the git clone command works satisfactorily. Are you able to reproduce the issue with this additional information?

However, when I make a copy of the local repository by modifying git-remote-hg, I can leave these extensions enabled.

Granted, in practice, I should not need any of these extensions if I am able to use git seamlessly as a frontend to mercurial, but given this and other issues I've reported, I don't thing git-remote-hg is ready for me to abandon hg altogether. cries

[felipec]

It work for me. Trying to interact with the original repo does not. This is a good enough reason for me.

That's not a good reason, it might be working by sheer luck.

A clone of a repository is not identical to the upstream repository (diff shows me a few differences)

So?

It lacks symmetry, as compared to the remote cases.

What it lacks in symmetry, it provides in efficiency.

Because we don't know how the upstream repo is being utilized, we can't be certain it's state will be properly maintained.

In which case you can create a mercurial clone manually.

I think at the least, the decision as to whether to make a local copy or operate directly on the local repository should be a configuration time option. I'm willing to supply this patch if you'll agree to merge it?

Maybe. First I would like to know why it fails.

As for the extensions, I also had hgk and mq enabled, and I did not have any problem. Is your repository available somewhere?

[felipec]

I tried the same extensions, the clone works fine for me:

[extensions]
hgk =
mq =
color =
record =
rebase =
graphlog =
hgshelve = ~/hgext/hgshelve/hgshelve.py
crecord = ~/hgext/crecord/crecord/

[felipec]

Which remote-hg script are you using?

[fingolfin]

While I don't know whether any extension was responsible for the problem reported here or not, let me just point out that in gitifyhg, we disable all extensions to make sure we are in a consistent state. Or rather, we prevent .hgrc from being loaded (by setting the HGRCPATH env variable). After all, a hg extension could potentially change APIs gitifyhg and remote-hg are using, so even if today there is no problematic extension (I am not sure about that), in the future one might pop up. Perhaps you want to consider something similar for remote-hg.

[felipec]

When such a time comes, we can deal with it. In the meantime there's no known extension that causes problems with remote-hg.

[felipec]

I think this is impossible. I can reproduce this error message by simply not importing any bookmark, then 'origin/master' doesn't point to a valid ref, and HEAD cannot be updated.

However, that cannot happen. For that to happen this check must succeed if tip and tip == head.rev() but that's impossible: tip will be 0, and the rest doesn't matter.

And I don't see how it could possibly be related to extensions. I've tried everything in my power to reproduce this issue, and it just doesn't happen.

If I don't receive feedback I'll simply close this as invalid. If there ever was a problem with remote-hg, I don't think it's there any more.

[felipec]

Since there's no way to verify this was a real issue, or maybe a problem in the reporter's setup, I'll close this as invalid.

Feel free to answer the questions above and reopen if the issue is still there.