I want to clone part of repository to non-tip changeset, so I use TortoiseHG -> Clone command, enter commit URL and clone. For some reason I get the clone to the last changeset, not that I wanted to clone.
How to clone to old changeset?
I've read that I can do this with git commands. Can I do it with TortoiseHG?
You clone not "commit", but "repository"
If you want to have partial clone, you have to read hg help clone
Procedure and syntax is common to all and any repositories, unrelated to BitBucket
To pull only a subset of changesets, specify one or more revisions
identifiers with -r/--rev or branches with -b/--branch. The resulting
clone will contain only the specified changesets and their ancestors.
hg clone -r <ID> SRC
hg help urls suggests second form of command
hg clone SRC#ID
GUI-way
In case of pure GUI in TortoiseHG "Clone" dialogue, expand "Options" enable "Clone to revision" and define this revision ID
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.
We have a repository with three named branches, I wanted to clone one of the branches. Is there a mercurial command to do that? If I provide the path (of branch) with hg clone I get 404 error.
hg clone http://your/repo -r branchname should do the trick.
Benjamin's right. But is that really what you want to do? In particular, you'll only get the changesets needed to make up that branch, and nothing else - and that would, for example, prevent you from pulling changesets in from the trunk or other branches. You might well be better off just cloning the entire repository and then simply working in the branch you are interested in; this will let you keep your repository in sync with the one you're pulling from more easily.
hg clone <URL> -b BRANCHNAME clone single branch, as requested
I know that this post is very old, but I had the same question. I found this trick:
hg clone /path/to/your/repo -r 0
hg pull -u -b branchname
I'm using Mercurial-4.0.2. In that we can specify the branch name by appending branch name with a # symbol in the clone url.
e.g.
hg clone https://user#cloneurl/my_product#MY_BRANCH
hg clone --verbose https://user#cloneurl/my_product#MY_BRANCH "C:\myCode"
I have a clone of a central repo at rev 2048. I want to remove the last 10 changesets on my local repo as if I was back in time two weeks ago. I suppose I could delete my local repo and do "hg clone -rev 2038" but that would be long (cloning the repo takes several minutes). Is there a way to just "unpull" some changesets?
Notes:
I'm not trying to backout the changesets. I'll eventually pull those changesets again from the central repo.
I'm not trying to update the working directory to an earlier version; I really want to affect the repository.
I don't have any outgoing changesets or pending modifications in my current repo and working directory.
Use the strip command:
hg strip -r 2039
This command is provided by the StripExtension. It is distributed as part of Mercurial 2.8 and later, but you do need to enable it first by adding the following lines to your .hgrc or Mercurial.ini:
[extensions]
strip =
Before Mercurial 2.8, it was part of the MqExtension.
To prevent you from accidentally destroying history, the command will generate a backup bundle in .hg/strip-backup/ which you can hg unbundle again if desired.
Cloning your local repo should be fast. I assume "several minutes" refers to a remote repo?
You can use hg clone <local repo> <new repo> -r <revision> to only clone up to a certain revision.
To remove a changeset that was already committed and pushed use :
hg backout -r (changeset number)
To remove a changeset that was committed but not pushed use :
hg strip -r (changeset number)
For versions previous to Mercurial 2.8, the Strip was part of the MqExtension.
In case you need to Enable the old MQ Extensions,
you can do it by adding this:
[extensions]
hgext.mq =
to your ~/.hgrc (or mercurial.ini) file.
The Strip information used to be here but now it can be found here.
I am looking for best practices to do the following:
When I need to implement a feature or fix a bug, I am creating new Mercurial repository from the main one (a trunk).
Then, within some days, or weeks, I am implementing the task in newly created repository, making commits and periodically merging with trunk. After the code in new repository will pass all code reviews, I should provide a repository with all changes collapsed into single revision.
My common way to do this (rdiff extension should be enabled):
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
patch -p1 < new.diff
hg commit
This works almost well except when there are binary files present in the changes from ~/repos/new. Another way could be:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg pull ~/repos/new
hg update
hg rollback
then resolve possible conflicts and manually commit the changes
Both ways look for me somewhat ugly and non-native, so I am looking how this operation could be simplified. I've played with rebase extension, but seems its hg rebase --collapse command does not work with workflow described above.
Any ideas are welcome.
Sounds like a good case for mercurial queues.
I do something similar with the histedit extension.
My workflow is something like:
clone a central repo
commit incremental changes to local repo
clone my local repo to make collapsed repo
hg histedit and select/discard/fold the revisions as needed
hg push the collapsed repo to central repo
pull central repo to local or refresh local from scratch
I ensure that my local repo never gets pushed to the central repo by adding an invalid default-push path to the .hg/hgrc file in the local repo root directory.
Solved: Just add
[diff]
git = True
to your hgrc file, and then use my first solution with rdiff extension, replacing patch with hg import:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
hg import new.diff
hg commit
Is there a way to clone a repo that comes with subrepos, but without having Mercurial pull all the subrepos?
It appears that while hg clone -U can be used to obtain an empty clone of a repo, there's nothing that would convince hg update to avoid starting off by pulling all of the subrepos.
I should point out that it is crucial to retain the ability to easily sync to the head revision after creating such a clone.
This should do what you want:
REM Take a new clone, but do not update working directory
hg clone --noupdate %REPO_PATH% %DESTINATION%
REM Update working directory but exclude the certain subprojects
hg revert --all --rev %BRANCH% --exclude %SUBREPO_PATH_1% --exclude %SUBREPO_PATH_2%
This answer may add more than the question required, but provides some valuable notes on working with Mercurial when you can't update do to a bad subrepository path or revision.
Step 1: Clone the repository without any updates
hg clone --noupdate source_repository destination_repository
Step 2: Use revert to get the right files
hg revert --all --rev revision_number --exclude subrepo_1 --exclude subrepo_2 ...
At this point, you have a new changeset; you may need to make sure the parent revision is correct. When I did this, my new changeset's parent was changeset 0. To fix this I had to set the parent changeset AND switch branches (since my changeset was on a different branch).
Step 3: Change the parent of the current changes
hg debugsetparents revision_number
hg branch branch_name
That should do it.
Found a hacky way. It still requires all subrepos to be checked out once, but afterwards they can be deleted.
Clone the whole lot, including subrepos. No way around this.
Delete subrepos
hg remove .hgsub
I tried to convince Mercurial to hg remove .hgsub before the subrepos are cloned, but the best I got is not removing .hgsub: file is untracked.
If you have a subrepo, a working directory must include some version of that subrepo. That version may be a fixed older revision if specified, or the tip if not.
You cannot update your repo without getting the subrepos; if you had a complete working dir without them, you shouldn't be using subrepos - use truly external repos instead.
If your subrepos are pegged against a certain remote version, then updates after the first will not trigger a subrepo update - they're already up-to-date. But for the initial creation of the working directory, you will have to do a remote pull.
You can trick Mercurial by munging the hgsubstate file. But really, your model and the conceptual model differ, so you're probably not a good match for subrepos if this is a concern.
edit: If you find yourself cloning and then updating to the tip many times, try using local branches or mq instead. That way you only have to do the initial clone once.