I typically backup my git repositories using git clone --mirror <repository> as it creates a functionally identical repository.
What is the equivalent functionality in mercurial?
Just hg clone <repository>. Each repository works the same as any other. The repo you clone will automatically be the default repo to pull from in the future. There is no way to access remotely the repository-, account- or server-local configurations as found in the .hgrc files, which includes the URLs of other repositories or hooks.
Related
I have a clone of a remote repository which supports Mercurial topics.
In this version of hg-evolve when the changesets are rebased (for instance) they are hidden.
I need to access the exact working directory at a hidden changeset which I do not have on my local clone. I have verified that other people's clones do have that changeset available via the --hidden flag of most mercurial commands.
I have tried:
hg --hidden clone
hg --hidden pull
but neither seem to have any affect.
Cloning the repository using hg clone --stream will include the hidden changesets, if they're available on the server.
I have a mercurial repo that has 5 sub repos (all mercurial on ssh servers).
I'd like to make a copy this repo and copies of all sub repos and put them on another server. Then on my workstation I need to push to those repos when pushing.
On my server so far I've done:
newserver> cd /my/newrepo/path
newserver> hg clone -U ssh://me#originalserver//my/repo/path
Followed by the commands on my worksatation:
workstation> hg clone ssh://me#newserver//my/newrepo/path
Then when I try to push, it pushes all subrepos to their original server
Re-read about Subrepositories in Mercurial, pay attention to "Remote Subrepositories" part.
In short: you have to rewrite subrepos definitions (make subrepositories local) by replacing URLs with relative path in .hgsub or clone each subrepository separately to ssh://newserver and changing URLs accordingly
PS: Username in ssh-URL is BAD IDEA (tm) - you have to use more natural HG-way of [auth] section in .hgrc
I have a dependancy as a subrepository (without write access to) in my project.
I'd like to add a few personal customizations to that subrepository - possibly using mq.
I also would love to be able to just clone the main repo to build it. Currently I have to:
clone the repo - with subrepositories getting cloned automagically
manually clone all the patchqueues for subrepositories
How do I get rid of step 2? Is it even possible without an outside script? (I'm using bitbucket if it makes any difference).
One notion is to make the subrepo not the repo to which you have no write access, but a clone of your own based on their repo.
cd myclones
hg clone http://notmydomain.com/their-repo my-clone-of-their-repo
and in your project's .hg/hgrc you use a [subpaths] section to map their URL to your local clone:
[subpaths]
http://notmydomain.com/their-repo = ../my-clone-of-their-repo
Then you end up with your repo using your local (read-write) clone of their repo to which you otherwise have read-only access. This has a few benefits:
faster -- you're only checking local repositories for all actions
writeable -- you can edit directoy in myproject/their-repo and commit and push (to your local clone)
And when you want to merge in their upstream changes you just go into ../my-clone-of-their-repo and hg pull and hg merge their updates into your customizations.
Summarised Question:
Are github-hosted sub repositories within a mercurial/kiln repository possible, and if so are they automatically updated/cloned when the parent mercurial repository is operated on by a hg clone or hg commit command?
Detailed Question:
Following on from my question that was answered so excellently here , some of my third party code is in folders I downloaded a while ago from opensource efforts on github. Since at that stage I was not using version control, those folders where just standard folders that now been incorporated as sub repositories in mercurial.
This is obviously not ideal, as for one thing, new versions of the libraries may have bug fixes, or new features I wish to use in the future. I also may need to locally customise some of the libraries.
I can see from reading this link that it possible to have mercurial "know" about those git server urls (and revisions), so I can then have mercurial clone the github hosted libraries direct from their parent repos.
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
What is also not clear is, if I were to do this, and it transpired that code might need to be customized from within that github-cloned repository, would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
Yes, clone of a Mercurial repository that contain subrepositories will trigger a clone of the subrepos too. It really happens on update. Mercurial notices the .hgsub file and issues the needed hg clone and git clone commands for you. It uses the information in .hgsubstate to know exactly what revision to checkout.
The subrepositories can be hosted anywhere. For a Git subrepository declared like
foo = [git]https://github.com/user/repo.git
Mercurial will simply issue the corresponding clone command:
git clone https://github.com/user/repo.git foo
It's then your reponsibility to later go into the foo repo and use Git to fetch new commits as necessary. After you fetch/pull new commits, you can make a top-level commit to record the new state of the subrepo in the .hgsubstate file. Use hg summary to see if a subrepo is dirty in this sense.
[...] would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
When you edit files and make a top-level hg commit, Mercurial will make sure to commit the subrepo first (if you use hg commit -S or if ui.commitsubrepos=True). If you make a top-level push, then Mercurial will always push the subrepos first so that you always have a consistent set of changes on your server.
Sometimes I have to return to a really old branch when I depended on a ton of external libraries. Updating to the current branch removes the source files for those dependencies, but the artifacts are left there, as well as a few folders and such.
I would like to have a way to force a mercurial repo to be as if I had just cloned it from the remote (master) repository. I don't want to just nuke my repo and re-clone it, because that forces me to download hundreds of MB from the remote server.
Why don't you clone not from remote server, but from your local repository? After that you could nuke your repo with old untracked files.
hg clone path_to_your_local_repo your_new_repo
After this you could map your new repo to your remote server in hgrc file
You can use the purge extension, or if you are on an UNIX-like system: hg st -nu0 | xargs -0 rm.