Is there a way to list remote branches in Mercurial like there in Git?
git branch -r
I want to list the branches on a remote machine (e.g. Bitbucket), so using:
hg branches -R `hg showconfig paths.default` --color false
fails with abort: repository not local
The mercurial API allows it:
from mercurial import ui, hg, node
peer = hg.peer(ui.ui(), {}, 'http://hg.python.org/cpython')
for name, rev in peer.branchmap().items():
print(name, node.short(rev[0]))
The above snippet produces:
default aaa68dce117e
legacy-trunk b77918288f7d
3.2 4787b9b2f860
3.0 4cd9f5e89061
3.1 5a6fa1b8767f
2.3 364638d6434d
2.2 61b0263d6881
2.1 e849d484029f
2.0 5fd74354d73b
2.7 260f3ad7af4b
2.6 f130ce67387d
2.5 b48e1b48e670
2.4 ceec209b26d4
No, it is not possible to list branches of a remote repository without cloning it to local.
If there is SSH access to the machine having the remote repository, then Mercurial could be used directly: ssh server hg -R path/to/repo branches.
If the repository is served with hgweb, then a list of branches can be fetched from that, using the raw style for easy parsing: https://www.mercurial-scm.org/repo/hg/branches?style=raw
BitBucket has its own API, where it is possible to get the branches, see their help and make a query like to a URL like https://api.bitbucket.org/1.0/repositories/mirror/mercurial/branches/
To expand on #gvalkov’s answer, you can make this a real extension by writing a file rheads.py:
from mercurial import hg, commands, cmdutil, node
cmdtable = {}
command = cmdutil.command(cmdtable)
#command('rheads', commands.remoteopts, 'hg rheads [SOURCE]')
def rheads(ui, repo, source='default', **opts):
"""print (possibly remote) heads
Prints a series of lines consisting of hashes and branch names.
Specify a local or remote repository, defaulting to the configured remote.
"""
other = hg.peer(ui or repo, opts, ui.expandpath(source))
for tag, heads in other.branchmap().iteritems():
for h in heads:
ui.write("%s %s\n" % (node.short(h), tag))
When configured in ~/.hgrc with
[extensions]
rheads = …/rheads.py
you can run it like:
hg rheads
I tried to make it a command that can be invoked outside any repository, just specifying the URL as an argument, but could not get the syntax to work:
commands.norepo += " rheads"
maybe you are looking for hg incoming -B This worked quite well for me. This shows the bookmarks.
Please note, this will not display remote only branches, it will only show branches that your local repository is aware of.
As the only relevant question to appear when googling "hg command line list branches", I thought I'd leave this here. When you run the following -
hg log | grep "branch" | grep -v "summary" | sort --unique
it outputs;
branch: branch1
branch: branch2
branch: branch3
branch: branch4
branch: branch5
Related
I have read only permission to an hg repo and am trying to develop and test changes to it locally. The problem is that I am in the middle of changing dev machines and am caught in a weird/akward state across the two machines.
On my old machine I made lots of changes to the repo, locslly. I just cloned the repo on my new machine, but obviously that doesn't contain the changes from my old machine. I need a way to createe a patch/diff from my local working copy on my old machine, and then apply them to my local working copy on my new machine. The problem is that I already commited (hg commit -m "Blah") the changes on my old machine to the distributed repo on it.
What set of specific commands can I use to create a patch/diff of my old machine and then apply it to the repo on my new one?
Update
I commited all changes on my old machine and then ran hg serve, exposing http://mymachine.example.com:8000.
On my new machine, where I had made some different changes (locally) than the changes from my old machine, I ran hg pull http://mymachine.example.com:8000 and got:
myuser#mymachine:~/sandbox/eclipse/workspace/myapp$ hg pull http://mymachine.example.com:8000
pulling from http://mymachine.example.com:8000/
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 16 changes to 10 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
So I run hg merge:
myuser#mymachine:~/sandbox/eclipse/workspace/myapp$ hg merge
abort: uncommitted changes
(use 'hg status' to list changes)
What do I do now?!?
You can use:
$ hg diff > changes.patch
To create a patch file, then:
$ patch -p1 < changes.patch
To apply that patch file on your new machine.
Well, that's actually fantastic, mercurial is a distributed version control system and you do not need to go via any patch file at all: simply pull the changes from your old machine to your new machine:
hg pull URL
where URL can be any network URL or also ssh-login, e.g.
hg pull ssh://mylogin#old.maschine.box or hg pull path/to/old/repository/on/nfs/mount
`
Alternatively you can also use bundle and unbundle. They create bundles which can be imported in the new mercurial easily and keep all meta-information.
hg bundle -r XXX --base YYY > FILENAME
where YYY is a revision you know you have in your new repository. You import it into your new repo with hg unbundle FILENAME. Of course you can bundle several changesets at once by repeating the -r argument or giving a changeset range like -r X:Y.
The least comfortable method is a via diff or export:
hg export -r XXX > FILENAME or equivalent hg diff -c XXX > FILENAME where you need to import the result with patch -p1 < FILENAME or hg import FILENAME.
The easiest way is to do this is to ensure that all work on your old machine is committed. Then use this command on it from the base of your repo:
hg serve
which creates a simple http server on this repo. The monitor should state the name of the http URL it is serving.
On your new machine, just pull from that URL.
Once you've pulled your old changes you can stop the hg serve process with ^C.
The advantages of this method are that it is very quick, and that it works on just about any system. The ssh method is also quick, but it won't work unless your system is configured to use ssh.
Answer to Update
The OPs update is asking an orthogonal question about how to merge changes pulled from a server with local changes. If you haven't already done so, try to digest the information in this merge doc and this one.
Merging is for merging changesets. The error is happening because you have local changes that haven't been committed which mercurial can't merge. So the first thing to do is to commit your local changes, then you will be able to merge.
But before you merge, I strongly recommend that you are merging what you think you are merging. Either ensure there are only 2 heads, or specify which head you are merging with. When merging, you have to be at one of the heads you wish to merge; it's usually better to be at the head with the most changes since the common ancestor because the diffs are simpler.
After you've merged, don't forget to commit the merge. :-)
I've got a project running under Mercurial and am finding a lot of situations where a file needs manually merging, when I believe it should be able to merge automatically. I am wondering whether there are any options that can be given to Mercurial to help it out in these areas.
The project has an underlying platform with a couple of hundred files that can't be edited on the project. When the platform is updated, the project gets updated versions of these core files outside of Mercurial. The sequence I'm seeing repeatedly is:
On central dev system (linked to the core platform update mechanism):
Get a new version of core platform.
Commit these changes e.g. hg commit -m "New platform release"
Push to central mercurial server
On my Linux box:
Commit local changes
Pull from central mercurial server, and try to merge
Find merge conflicts on core files
The last two core files I've had to merge have no changes between the base and local versions (the access time is updated during a build, but the content is the same). The only changes are on the remote revision I'm merging with.
The only non-standard configuration I'm aware of is that the central mercurial instance is running under Rhodecode, with a commit hook setup to update a Redmine repository.
Is there anything else that can be configured in mercurial to help it figure out merges?
You can redo a merge with --debug to get more information about a merge. That is, take your repository and do
$ cd ..
$ hg clone my-project -r 123 -r 456 merge-test
where 123 and 456 is the two parents of the merge you want to examine closer. Then run
$ hg merge --debug
to see what Mercurial says. It should look like this if the file foo has only been changed in the branch you're merging in:
$ hg merge --debug
searching for copies back to rev 2
resolving manifests
overwrite: False, partial: False
ancestor: 932f5550d0ce, local: b0c286a4a76d+, remote: c491d1593652
foo: remote is newer -> g
updating: foo 1/1 files (100.00%)
getting foo
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Here I was on revision b0c286a4a76d and merged with c491d1593652.
You can also use
$ hg status --rev "ancestor(b0c286a4a76d, c491d1593652)" --rev "c491d1593652"
M foo
$ hg status --rev "ancestor(b0c286a4a76d, c491d1593652)" --rev "b0c286a4a76d"
M bar
to double-check which files have been changed between the ancestor revision and the two changesets you're merging. Above you see that I changed foo on one branch and bar on the other.
If you see a platform file appear in both status lists, well then something went wrong in your procedures and this can explain the merge conflicts.
If this isn't enough to figure out what went wrong, then I suggest asking this question on the Mercurial mailinglist. That's a great place for discussion and bug-hunting — much better than Stack Overflow.
We have two repositories: myapp and myapp-1.1. We merge myapp-1.1 into myapp.
To see if there are changes in 1.1 that need to be merged I do this:
cd c:\myapp (local clone)
hg fetch (fetch from remote myapp repo)
hg in ssh://hg/myapp-1.1 (see what needs to be merged in from remote 1.1 repo)
This works - but is there a better way? Is there a way to do this without requiring the local myapp clone?
Mercurial can't do much with remote repositories except for some variant of pushing to, or pulling from them.
As such, anything you want to ask Mercurial to do has to be done with a local clone.
So no, there is no way to have Mercurial check if two remote repositories needs to be merged.
What's the problem with having local clone, exactly?
If you want to isolate all operations on machine the repo is located, you could do the following:
$ ssh $hg_box
$ cd myapp; hg in /myapp-1.1
This may seem like the obvious response, but since Mercurial is a completely distributed source control system, and each repo is stand alone, is it possible for you to actually go to the box that has myapp and fetch directly from myapp-1.1? I know most dev teams keep some kind of centralized repository, but that doesn't preclude the use of Mercurial directly from the box that you have as your 'central' repository. It's all still local and remote repositories.
This assumes that you want to fully merge myapp and myapp1.1. Otherwise, pretty much by definition of what you're doing, you have to clone myapp to another full repository, then merge it with myapp-1.1.
Assuming neither the remote repo nor the local repo allows multiple heads per branch, this command should tell if the local repo has the head of the remote repo at a given branch:
hg log -r $( hg in -b branch_name -n -l1 -q --template "{node}\n" )
If local repo doesn't have that changeset, but has outgoing changesets at "branch_name", then typically it should be an indicator that merge is needed.
I am working with Git repositories in the following way:
I have the master repository and several remotes on the different production machines.
I am pushing the production code to the remotes and restart the services for the changes to take effect.
I am about to switch from Git to Mercurial and I would like to know ahead how I can achieve something like that.
You add entries to the [paths] section of your local clone's .hg/hgrc file. Here's an example of a section that would go in the .hg/hgrc file:
[paths]
remote1 = http://path/to/remote1
remote2 = http://path/to/remote2
You can then use commands like hg push remote1 to send changesets to that repo. If you want that remote repo to update is working directory you'd need to put a changegroup hook in place at that remote location that does an update. That would look something like:
[hooks]
changegroup = hg update 2>&1 > /dev/null && path/to/script/restart-server.sh
Not everyone is a big fan of having remote repos automatically update their working directories on push, and it's certainly not the default.
if you want to add default path, you have to work with default in your ~project/.hg/hgrc file. As Follows:
[paths]
default = https://path/to/your/repo
Good Luck.
You could have a look at hg-git GitHub plugin:
adding the ability to push to and pull from a Git server repository from Mercurial.
This means you can collaborate on Git based projects from Mercurial, or use a Git server as a collaboration point for a team with developers using both Git and Mercurial.
Note: I haven't tested that tool with the latest versions of Mercurial.
If you're on Unix and you have Git installed, you can use this bash function to readily add a path to the remotes without a text editor:
add-hg-path() {
git config -f $(hg root)/.hg/hgrc --add paths.$1 $2
awk '{$1=$1}1' $(hg root)/.hg/hgrc > /tmp/hgrc.tmp
mv /tmp/hgrc.tmp $(hg root)/.hg/hgrc
}
Then invoke it with:
$ add-hg-path remote1 https://path.to/remote1
If someone would like to build a Powershell equivalent, I'd like to include that as well. Other potentials improvements include error checking on the parameters and factoring out the call to $(hg root).
I have a platform neutral mercurial code repo called "Simulator"
and want to apply patches that target specific platform's optimizations before a build.
According to the guide we can accomplish this by the use of patches with guards.
Windows Experimental.patch +windows
Unix Experimental.patch +unix
Mac Experimental.patch +mac
However its starting to get cumbersome because our patch queue contains 100+ patches named like windows-memory-optimization.patch +windows, unix-memory-optimization.patch +unix, windows-io-experimental-bug-fix.patch +windows, etc etc. We organized it as groups in the series file, but the file is getting huge and using qseries / qapplied is getting unmanageable
Instead we would like to have a queue for windows, unix and mac.
So that patches can be organized as:
Windows Patch Stack: memory-opt.patch, io-opt.patch, etc
Unix Patch Stack: disk.patch, graphics.patch, etc
Mac Patch Stack: io-fix.patch, io-opt.patch, experimental.patch, etc
Then swap the patch stacks for each platform in and out of the simulator repo. So that I can work on the windows patch stack and pop/push various subsystem optimization patches and work on them independently of the unix or mac patch stacks.
It does not look like I can do that, other than making 3 different repos specific to the each platform and maintaining the patch stacks that way.
Is there a way to, other than manually copying the .hg/patches directory in and out of the repo, to accomplish "swapping" patch stacks?
Interesting use of Mercurial Queues :)
I assume here that you are already versioning your mercurial queues somewhere. If you don't/for those that don't know how to do this, have a look at the relevant section from the hgbook: it's a great way to collaborate/save incrementally your work without applying the patches.
Three named branches
It should be possible to maintain three different named branches, one for each platform, in your MQ repository.
To switch platform, just switch the active branch.
(with alias mq='hg -R $(hg root)/.hg/patches')
First create a windows branch:
$ mq branch windows
marked working directory as branch windows
created, but not yet committed.
Do some stuff, add patches:
$ hg qnew windowspatch
... do some stuff
Refresh, pop and commit:
$ hg qref
$ hg qpop -a
$ mq ci -m 'new windows branch'
You now have the default branch and the new windows branch:
$ mq branches
windows 65:5fd4ef0b96c9
default 64:06c1a56a3c08 (inactive)
Now create an Unix branch.
First switch back to the base default branch:
$ mq up default
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
Create a new unix branch and add a unix-specific patch:
$ mq branch unix
marked working directory as branch unix
$ hg qnew unixpatch
... blahblah
$ hg qref
$ hg qpop -a
$ mq ci -m 'adding unix branch'
$ mq branches
unix 66:c51bb2c7b413
windows 65:5fd4ef0b96c9
default 64:06c1a56a3c08 (inactive)
Usage
Don't forget to qpop -a before operating on the mq repos...
Push all the windows patches
$ mq up windows
xx files updated, yy files merged, zz files removed, ww files unresolved
$ hg qpush -a
Three physical repos
Maintaining three separate (mercurial queue) branches can look a bit scary. If so, you can just use three different MQ repositories: one for each platform, each of them versioned in a different place.
For example :
$ cd mqs
$ hg qclone mq-windows windows
$ hg qclone mq-unix unix
$ hg qclone mq-mac mac
To work on different platforms, just switch folders (repos). The concept is similar to the first approach. But instead of having three internal branches in one MQ repo, you use three separate MQ repos.
To make an equivalent Windows alias for "mq", create a batch file in the same directory as "hg.exe" (e.g., "C:\Program Files\TortoiseHg"), name it "mq.cmd", and paste this code:
#echo off
FOR /F "tokens=1 delims=" %%A in ('hg root') do SET hgRoot=%%A
hg -R %hgRoot%/.hg/patches %1 %2 %3 %4 %5 %6 %7 %8 %9
I know this question is old, but may be someone could be interested to know there's another solution. I think this wasn't possible at the time the question got asked, but here it is more info regarding this situation: Multiple Patch Queues on MQ