Issue #85 resolved

qclone over SSH doesn't clone main repo (BB-500)

Ches Martin
created an issue

I'm not sure if I fully understand how these are supposed to work, but my intuitions can't be too far off. Here are my experiences:

I first created a patch queue for my test fork of cx (, called cx-ches-patches. I forgot to check the option to omit the series file, so I deleted the repo and tried to create a new patch queue with the same name, only choosing the omit option this time. The creation stalled, and still shows the barber pole when I try to visit the page for the repo.

I created another patch queue called cx-ches-patches2. Honestly, I think I might have forgotten to omit the series file again (it shows an 'Automated Init' changeset -- is that what that should be? Doesn't seem to actually have a series file though -- see #61 maybe). I pushed an existing mq patch repository to this successfully, and can clone the repo now. However, on bitbucket it appears to be empty.

Finally, I created a private patch queue for a private repository. This time I definitely omitted the series file and the repository shows zero revisions on bitbucket. Again, I successfully pushed an existing mq patch repo here and can clone it, but it still shows up as empty on the web.

Have I done something wrong? Hope this report is useful in troubleshooting.

Bitbucket is great so far, keep up the good work!

Comments (16)

  1. Jesper Nøhr


    I pushed in some fixes on this yesterday, but I haven't deployed them live yet. They should fix most of the problems here, though.

    The 'omit series' option does not create an empty 'series' file in the repository, allowing you to use your own. For importing existing patch queues, this is probably what you want.

    The thing about patch queues is that MQ uses a special versioned repository that resides in '.hg/patches' of the main repository. Cloning the repo directly will not give you anything but a copy of the main repo. What you want to do is use 'qclone', which is also stated in the quickstart guide, which you probably didn't see since you got the series file, and the quickstart only shows on zero revs. This is of course unintuitive, and I'll have a go at it later.

    I also have to write up a thorough guide on how to work with patch queues on bitbucket, but here's a short tour:

    1. Create a patch queue for repo A, let the url be /ches/test/patchtest/ 2. qclone this by doing hg qclone 3. Notice that your clone does 2 things: cloning the main repo (A) and another repo (your patch queue, will be in .hg/patches/) 4. Make a new patch by typing 'hg qnew testpatch' 5. Make some changes, then 'hg qrefresh' 6. If you go to .hg/patches/ you will now see two files: series and testpatch 7. Both should have status 'added' if you do 'hg status' in .hg/patches/ 8. You can then commit them, either from .hg/patches/ directly with normal hg commands, or you can use 'hg qci' from the main repo root 9. cd to .hg/patches/ and 'hg push' your changes to bitbucket 10. Your patches will appear on the patch queue repo page on bitbucket and you can apply them online, etc.

    Let me know if this clarifies anything for you, and any problems you might have.

  2. Ches Martin reporter
    • changed status to new
    • removed assignee

    Also, I don't understand how this is qclone-compatible (see #3).

    I think my expectation of what that means, and probably the creator of that issue also if I'm reading correctly, is that if I create a patch queue for cx-ches called cx-ches-patches, I would then be able to qclone cx-ches and conceptually have cx-ches-patches cloned into cx-ches/.hg/patches.

    Given that bitbucket allows multiple patch queues per repo though (which is quite neat), the approach would have to be something like parren suggested I guess: automatically create a fork of the base repo when a patch queue is created, and associate the queue with that fork instead of the base repo. Then qcloning the fork gets a full repo and its versioned patch queue.

  3. Jesper Nøhr

    The problem with forking is that you will get a point-in-time clone of that repository, and you can't follow the upstream, which is the point of a patch queue. It also makes it a lot easier to rebase.

    You can 'hg pull -u' in the repo root locally to follow upstream and keep your patches up to par. If you want to patch on a fork, it's as easy as doing a fork, then making a patch queue on that :-)

  4. Ches Martin reporter

    Thanks for your response Jesper.

    I should have been more clear: I *do* understand how mq works, and how to version mq patches -- just trying to understand in context of bitbucket :-) I tried directly cloning patch queue repos just to verify that they do in fact contain my patches and changesets, even though they appear empty on bitbucket.

    One example is which is private, but maybe you've got super powers :-) I pushed to the that repo from an existing local patch queue I had for the project (qinit -c from the main inav2 repo). The patch queue was created with series file omitted, hence quick start instructions are showing up. It *does* have patches in it now though -- I pushed to it and I can clone it directly to verify that they're there. The repo just looks empty in bitbucket.

    Trying to qclone the base repository that the patch queue is associated with doesn't work -- it says it can't find the patch repository.

    Maybe the fixes you've got ready to deploy already address this. Or am I still not seeing something clearly?

    Also, I agree with you on the fork/patch queue thing.

  5. Jesper Nøhr


    First of, I don't have superpowers. Bitbucket works the same way for me as it does for you :-)

    Second, the problem you're experiencing sounds odd indeed. I'd be interested in following your workflow on this; is there any chance you can frequent either IRC, or add me on some kind of IM? We're on or you can ping me on (Gtalk).

  6. Ches Martin reporter

    Jesper and I worked through this on IRC. Part of the problem is getting SSH to do the same magic you guys are doing for HTTP when pushing to patch repos.

    It will all be documented officially of course, but if anyone needs a guide in the meantime, I wrote up a long and detailed one on my blog:

    Sorry the formatting sucks a bit, especially for code. I'm long overdue to overhaul that thing.

  7. Jesper Nøhr

    Thanks for the write up Ches,

    I've posted a comment on your blog, clarifying a few things.

    Regarding the few things that say "this does not work yet", can I ping you when they're fixed, and you can remove them? ;-)

  8. Ches Martin reporter

    Argh, my blog somehow ate your comment when I tried to publish it from the moderation queue, and I didn't have a DB backup that contained it. So, I reproduced your comment from an email notification and may have changed formatting a little -- let me know if anything is wrong!

    Of course, ping me when fixes are deployed and I'll gladly remove those bits :-) Also, in regard to paraphrasing for the official docs, I'd be happy to explicitly put a Creative Commons license on the article if you want to use any of it directly. Just let me know!

  9. Ches Martin reporter

    There's still a thing or two with SSH that can be confusing here. Namely:

    1. The redirection magic for the base of a patch repo doesn't work as it does for HTTP, so
    2. If you qclone a patch repo using SSH, you get the .hg/patches stuff but not the base repo. It does set appropriate paths in .hg/hgrc and .hg/patches/.hg/hgrc just like the HTTP method does.
    3. I haven't recently tested pushing to the base of a patch queue repo over SSH -- will it happily route instead to the 'parent' of the patch queue?

    Clearly this would confuse new users figuring this out, and it's troublesome because I just make a habit of using HTTP all the time currently, and hence have to type my password a lot.

    Otherwise, I think clear documentation for all of this is all that remains for this issue. Both a help doc and the blurb on '/hack/' pages as cvrebert mentioned.

  10. Log in to comment