Is it possible to temporarily disable a hook when running a mercurial command? e.g., something like:
hg push --no-hook
According to this bugfeature, the following skips local hooks:
hg --config alias._pull=pull _pull
Obviously this is a hack, but it has worked since 2011, and is the only way to skip local hooks given the lack of a '--no-hooks' option.
You can't disable a remote repository's hook. But you could enable or disable a local hook via --config option:
$ hg commit -m test --config 'hooks.commit.info=set | grep "^HG_"'
If this is an outgoing or preoutgoing hook that is locally configured, you can disable it by commenting out its entry under [hooks] in .hg/hgrc. If this is a hook configured on the repository that you are pushing to (changegroup, incoming, prechangegroup, pretxnchangegroup), you will have to comment out its entry under [hooks] in the target repository's .hg/hgrc (if you have access to it).
Related
My .hg/hgrc file has the line:
default = http://some/remote/repository
Is there a quick command to print the tip revision of that repository (which may or may not be inside my local repository)?
You can use the identify command like this:
$ hg identify $(hg paths default)
This is one of the few commands that can operate on a remote repository. If you need more information about the remote repository, then I suggest you take a look at hg incoming.
The following returns the latest changeset number (tip) of a remote repository:
hg identify --id http://www.myrepo.com
hg id default
This is a shorter form of "hg identify $(hg paths default)".
I have some pretxncommit hooks in my local mercurial repository, those hooks are used to check that the commit message includes a reference to a ticket and some other sanity checks.
My problem is that when I try to use mercurial queues, commands like qnew try to run these hooks and the one of the ticket checking fails, I have seen the same problem with histedit and similar extensions.
Why are pretxncommit hooks executed with these commands? Do they run some kind of internal commit?
How can I make these hooks to be run only on commits?
Yes, a qnew creates a real commit and thus invokes all the relevant commit hooks. You can confirm this for yourself by temporarily disabling MQ while you have an MQ patch applied and looking at the log.
There is no way to make the pretxncommit hook apply to only some commands except by jury-rigging something with other hooks:
$ cat .hg/hgrc
[hooks]
pre-qnew = touch .hg/skiphook
post-qnew = rm .hg/skiphook
pretxncommit = test -e .hg/skiphook || echo not skipping
$ hg rm README # make some change
$ hg qnew asdf # no hook
$ hg qpop
$ hg rm README
$ hg ci -m asdf
not skipping
Here our pretxncommit hook makes sure a specific file doesn't exist before running its (trivial) hook, and the pre-/post-qnew hooks create the file and clean it up.
The function abort_commit_to_wrong_branch in https://stackoverflow.com/a/19349636/350713
shows an approach to run a hook only on a "real" commit, not an MQ commit.
The idea is to check for the attribute _committingpatch in repo.
If repo has '_committingpatch' attribute, then it is an MQ commit in progress.
The relevant line is
if hasattr(repo, "_committingpatch"):
This is mentioned in the function newcommit in
http://hg.intevation.org/mercurial/crew/file/7032dcff290c/hgext/mq.py#l293
pretxncommit works with all changes (recordable) inside repo
if you want ignore mq-operation, you could look for the changeset parents and see if that's a descendant
of the qparent/qbase tag or see at WC. Smth. like (dirty from head, not from test) hg id -tr .
Or (maybe delirium) - when you work with MQ, you work with qtip always, sn't it?
>hg parents
...
tag: qtip
tag: tip
..
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).
Being very familiar with the subversion workflow and that fact that 99.9% of the time my computer is connected to the internet, I don't like doing 'hg ci' and 'hg push' separately.
I remember bzr had a 'checkout' command that would bind subsequent 'commit' commands to automatically commit directly to the server ('push').
Does mercurial have something similar to this?
PS: Writing a shell script or alias that runs 'hg ci $* && hg push' would be the last thing I'd do.
You could add a hook to run push after a successful commit.
EDIT: I just tried it out and it seems to work fine. I added the following to the .hg/hgrc file of the repository I wanted to activate automatic pushing for:
[hooks]
commit.autopush = hg push
EDIT 2: Also, you don't have to worry about something like this:
You're in a repository that you don't want to automatically push.
You use hg -R ~/another-repo-that-autopushes commit to commit in a different repo that does automatically push.
Will the hg push hook end up pushing the changes in the current directory instead of the one you're committing in?
No, it won't. According to the page I linked:
An executable hook is always run with its current directory set to a repository's root directory.
It's an edge case, but Mercurial handles it correctly.
I can't clone my repository via http:
abort: 'http://MYREPO' does not appear to be an hg repository!
Firstly, I created a new repo by hg init MYREPO followed by adding some file and commit.
The dir with my repo is password protected but there is no sign of problem because of it, I tried both methods of cloning:
(on my local machine)
hg clone http://MYREPO my_repo
and
hg clone http://user:password#MYREPO my_repo
Permissions of repo dir are: drwxrwxr-x
I can clone this very repository on my remote machine (the same repo is on) without any problems.
What could be possibly wrong?
UPDATE:
Looks like you're getting confusing between repository and hostname
If running "hg serve", "hg clone http://USER#HOST:8000" where host can be you machine's IP or the hostname (type "hostname" on linux or try "ping localhost"). You can change the default port from 8000 by passing a --port #### to hg serve.
If you want to do it over ssh, "hg clone ssh://USER#HOST//PATH/TO/YOUR/REPOSITORY". Suppose you made an repository in your home directory called MYREPO then you would do this: "hg clone ssh://USER#HOST/~/MYREPO"
You can only clone your repo via http is something is serving that repo over http. Mercurial provides a built in http server for you. Run "hg serve" while inside of your repo then attempt to clone it from another location (or another command shell). If you just want a local clone, you don't need to use http ("hg clone ").
Also, try "hg help clone" and "hg help serve" for details.
weirdly, cloning with ssh requires a non-intuitive extra forward slash.
this works for me on a host with ssh running on port 43211
hg clone ssh://example.com:43211//repos/myRepo ./myRepo
the double slash after the port number works, but a single slash there results in the ".hg not found" error
besszero is right, but why don't you clone using SSH if you are gonna use username and password anyway?
hg clone ssh://machine_ip//your/repo/location your_repo
It's also safer if you don't want to open another port for mercurial's http server and you don't need the hgweb features, the traffic is also encrypted. The only con is that you have to log in to checkout, but HTTP doesn't work for pushing back the changes, at least not in my experience.
Argh... One need to be careful with .htaccess configuration. In my case I needed to add 'hgwebdir.cgi' to the path to clone... Thanks for the answers though!
SSH seems logical but somehow I couldn't use it with user other than my local:
hg clone ssh://MY_REMOTE_USER#MYREPO
remote: abort: There is no Mercurial repository here (.hg not found)!