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"
Related
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
Is there an easy way of getting all the heads of current branch?
Currently I get the current branch name with hg branch and after that perform hg heads branchname.
So is there any shortcut to current branch name to prevent of using 2 commands?
PS: in bash we can do
hg heads `hg branch`
but is there native and cross-platform mercurial solution using revision set language.
Yes, use
$ hg heads .
The hg heads command takes an optional revision identifier. If you run hg heads X, you will get the heads of the branch of X — note the extra indirection. This means that you can use . (which means the working copy parent revision) to get heads on the current branch.
TBT!
hg heads -r "min(branch(.)) and branch(.)"(min() because "If STARTREV is specified, only those heads that are descendants of STARTREV will be displayed.")
hg log -r "head() and branch(.)"
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.
If there are two branches, and I have been doing work on the default branch, I think one way to push to the foo branch of the other clone is
cd ~/development/clone2
hg up default
hg pull ~/developmet/clone1
hg up foo
hg merge default
or
cd ~/development/clone1
hg up default
hg push ~/developmet/clone2
cd ~/development/clone2
hg up foo
hg merge default
These 2 methods work exactly the same? (one is a pull, one is a push).
Is there an easier way to directly push clone1's default branch to clone2's foo branch? thanks.
(I use clone 1 to see all the changes I have done (without seeing anybody else's changes), and use clone2 to merge and integrate with other team members)
You can always push and pull a single revision and all of it ancestors using:
hg push -r revision ~/development/clone1
or
hg pull -r revision ~/development/clone2
There's no way to "push to another branch" because you'll always have to merge the two different branches manually
Both methods you described work exactly the same, but the first one is recommended (Always do the merge work in your clone, not the integration repository or somebody else's clone)
Maybe is an intentional omission but in both examples you have to commit the result of the merge and in the first example you have to push the merge changeset back to clone2
So in ~/development/clone1 do:
hg up default
hg pull -u ~/development/clone2
hg up foo
hg merge default
hg ci -m 'merged default into foo'
hg push ~/development/clone2
If you do this a lot you may consider adding this lines to your ~/development/clone1/.hg/hgrc file
[paths]
default = ~/development/clone2
This way you can omit the repository path when you're pulling and pushing from the integration repository
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