I have colleagues who push multiple heads by using the --force switch because they haven't merged properly.
Are there any ways to prevent this?
You can do this with a pretxnchangegroup hook on the server side.
Here are a few examples: http://www.softwareprojects.com/resources/programming/t-mercurial-hook-forbid-2-heads-1910.html
All those hooks are doing is making sure that after the changegroup is applied that there's still only one head (or only one per branch if you want to get fancy).
Tell them they shouldn't do it, and enforce the workflow with hooks on a repository you control.
At work, we restrict it to one head / branch. Essentially replace forbid_2head.sh with this:
#!/bin/bash
# Ensure only one head per branch in hg repository
for BRANCH in `hg branches -qa`
do
COUNT=`hg heads -q $BRANCH | wc -l`
if [ "$COUNT" -ne "1" ] ; then
echo "Error: Trying to push more than one head to branch $BRANCH."
exit 1
fi
done
exit 0
This is the best from top proficient developers: http://hg.python.org/hooks/file/default/checkheads.py
Visit http://hg.python.org/hooks/file/default/ for list of another useful hooks.
You could revoke their push rights to the repository that they are --forceing to, and make them push to a different server, or submit changes via patch.
First off, I'd tell developers that a --force push is not allowed.
I'd also use the server side hook solution as prescribed above, and in the hook add an email to everyone stating WHO tried to push multiple heads into the central repo [and then format his hard drive ;)]
Related
Is it possible to detect if a commit creates a new bookmark or branch via hooks in .hgrc?
I've tried to see if I can find out using hg log, but it just shows on what branch/bookmark the commit has been created: http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html
There don't seem to be hooks for it: http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html
It would make sense I suppose that there isn't a hook for it, because it is also not possible to make a commit which is 'just' the creation of the branch indicating branches/bookmarks only exists when added to a specific commit.
I figured I could check hg branches and hg bookmarks before and after each commit and determine which are removed and added, but is there a cleaner way for detecting branch/bookmark adds/removes?
The pushkey and prepushkey hooks can detect the addition, deletion, and moves of bookmarks.
In hgrc:
[hooks]
prepushkey=echo %HG_NAMESPACE% %HG_KEY% %HG_OLD% %HG_NEW%\n >> out.txt
HG_NAMESPACE will contain "bookmark" and HG_KEY will contain the name of the bookmark.
HG_OLD will contain the hash of the commit the bookmark was before the operation. It won't be set if the bookmark is being created.
HG_NEW will contain the hash of the commit the bookmark will be after the operation. It won't be set if the bookmark is being deleted.
Bookmarks
Bookmarks-handling does not require commit
Bookmark can be created|modified for any changeset in history, not only for current
Bookmark(s) can appear as result of data-exchange (pull|push), not local user's actions
Only part of all possible cases can be covered by hook
Branches
Changing branch always reflected in commit
Branch in changeset may differ from parent's branch not only as result of hg branch (see "merge branches" and "mergesets") - and I haven't nice and easy and ready to use solution for this case
Common notes
You can use standard precommit hook (executed before commit and can enable|disable commit) for testing different conditions in commit or or pretxncommit
Mercurial template-engine has keywords for branch and bookmark for using in hg log -T
In pretxncommit hook commit already exist, but not finalized - it means you can manipulate with commit's data using -r tip and tip's parent in any Mercurial command
Dirty skeleton for hook's body
hg log -T "{KEYWORD}\n" -r "tip + tip^" | ....
where KEYWORD may be branch or bookmarks. Result of log is two-strings output, which can be identical of different (not sure for bookmark, TBT!!), which you have to compare (as you want and can)
PS: Idea inspired by EnsureCommitPolicy Wiki and Mercurial pre commit hook topic here
I want to write a hook that performs some actions each time I run hg branch branch_name (e.g. set "In progress" status for a JIRA ticket), but I can't find anything that runs during branching. Is there a way I can do it?
The is a pre-<command> hook (with a hyphen) for each command. Note that is is distinct from any hook that may exist without a hyphen, sush as precommit.
Thus you can do:
[hooks]
pre-bookmark = /usr/bin/notify_jira.sh ${HG_ARGS#bookmark }
to invoke:
/usr/bin/notify_jira.sh PROJ-415
when you run:
hg bookmark PROJ-415
Full details on the generic pre-<command> (and post-<command>) hooks can be found on the hgrc man page.
It also looks like pushkey hook might do what you want, but pre-bookmark (or better, post-bookmark) is probably more straightforward.
The setup:
a laptop L
an office server hosting various repositories SOffice
a customer's database server SCustomer
I'm writing code on L for a customer, and regularly want to push it both to SOffice as well as SCustomer.
I know I could use a changegroup hook to push to a third repository from the second (as described in this answer), but this requires that the second can reach the third network-wise.
In my case, each is behind a firewall, and only my laptop typically accesses both through a VPN (or by being physically there). I could set up the VPN on SOffice to get to SCustomer, but I'd rather not.
Is there a way I can, say, set default to two repositories?
You can't default to two repositories, but you can define more than one repository in your hgrc file :
[paths]
default= /path/to/first/repo
scustomer = /path/to/second/repo
You can then push to the scustomer repository explicitly :
hg push scustomer
If you want to automate the process of pushing to both repository at once, I'm not aware of a Mercurial method to do it, but it is really easy to create a shell script, alias or something else to run both commands one after the other.
You can even use a hook on the repository to automatically push to the other one, but you will have to discriminate between a "manual" push and the automatic push in the hook, and I'm supposing this will be really messy.
Could you create a second clone of the repository with a hook that automatically pushes to both of the external repositories? Then push from your working clone to the second clone.
There's a MultirepoExtension that adds commands for doing any operation on multiple repositories.
Or you could create an alias to push to both like:
[aliases]
pushboth = !$HG push http://first ; $HG push http://second
or you could create a pre-push hook that pushes to the other one. Something like:
[hooks]
pre-push = hg push http://second
But I like (and upvoted) krtek's answer the most. Just give each a path alias and run push twice with the short names instead of the URLs.
I have a "central" repository that I want to ensure that no one pushes changes in to with a wrong user name.
But I can not figure out how to make a hook that tests the user name against a positive list. I have found in the Mercurial API a ctx.user() call that seems to be what I want to test my positive list against.
Also the hook could be a precommit hook that is distributed as part of the repository clone or it could be a hook on the central repository as a pre-incoming or something like that.
Any help or pointers would be greatly appreciated.
I have posted two functional examples on Bitbucket. Both examples are for searching a commit message for some specifically formatted text (like an issue tracked case ID), but could be easily modified to check a user against a list of valid users.
The first example is actually a Mercurial extension that wraps the 'commit' command. If it fails to find the appropriate text (or valid user in your case), it will prevent the commit from occurring at all. You can enable this in your .hgrc file by adding these lines:
[extensions]
someName = path/to/script/commit-msg-check.py
The second example uses a in-process pretxncommit hook, which runs between when the commit has been made, but before it becomes permanent. If this check fails it will automatically roll back the commit. You can enable this in your .hgrc file by adding these lines (assuming you kept the same file/function names):
[hooks]
pretxncommit.example = python:commit-msg-check-hook.CheckForIssueRecord
You can execute any Python code you like inside of these hooks, so user validation could be done in many ways.
Thanks for the examples dls.
In the end I decided to run it as a pretxnchangegroup hook and then use the hg log and grep to test the author field of the commits:
[hooks]
pretxnchangegroup.usercheck = hg log --template '{author}\n' -r \
$HG_NODE: | grep -qe 'user1\|user2\|etc'
It does of course not provide a very good feedback other than usercheck failed. But I think it is good enough for now.
As the definite guide aptly points out (search for "Tags and cloning"):
When you run hg clone -r foo to clone a repository as of tag foo, the new
clone will not contain any revision newer than the one the tag refers to,
including the revision where the tag was created. The result is that you'll
get exactly the right subset of the project's history in the new
repository, but not the tag you might have expected.
It means hg tags in your new clone does NOT show the foo tag. Same thing happens if you had cloned before foo tag was added, and you do hg pull -r foo.
(Digression: tag is about the only thing I don't quite get in hg. I understand there are advantages (e.g. merge) in putting it in a changeset, but it always feels weird to have meta data mixed with source code.)
It should be obvious that I'm asking for an automated way, instead of pulling the tag changeset as a separate manual step.
I know I could check for this scenario in an incoming hook (so it works for both clone and pull), or wrap clone and pull.
But is there a better/easier way?
UPDATE hg bug tracker already has this issue.
You want a giant hack with bash and an embedded Perl script? Well, here it is...
#!/bin/bash
if [[ "$1" == "" || "$2" == "" || "$3" == "" ]]; then
echo 'hgclonetag <src> <tgt> <tag>'
exit 1;
fi
REV=`hg log -R $1 --rev $3: --limit=2 | perl -F: -lane 'if (/:([\dA-Fa-f]+)$/) {print $F[2] if defined($flag);$flag=1;}'`
hg clone --rev $REV $1 $2
This invokes the hg log command to extract the revision number after the first tag-related revision and then clones to this revision.
Currently this does not work on remote repos: -R switch only works on local repos unfortunately.
The more I think about it the more I'm convinced the right answer is to just clone everything and update to the tag, which can be done in a single step:
hg clone http://host/path#tagname
That gets you everything and then does hg update to tagname which sets your working directory to the correct revision. Given delta compression that's not necessarily much larger, and if it is you can automate cloning the bulk of it from a previous local clone.
There is a postclone hook. It's called post-clone (the hgrc manpage shows a post-ANYCOMMAND and pre-ANYCOMMAND exist) though as you pointed out you could also use *changegroup or update hooks too, since clone uses both of those functions (unless you suppress update with -U).
What about just adding a --localtag so you have the name but not the extra changeset if you need it for reference only. Something like
hg clone -r tagname URL
hg tag --local tagname
which you could easily build into a shell alias.
Other than that there's not necessarily guaranteed to be a way to have revision X and the revision where revision X is tagged without also having other revisions you don't want since the tag could have been applied after other work was done. You can, of course, always update to 'X' and to have subsequent changesets in you working dir, but they'll still be in your repo.
Honestly, once I figured out that the tag name doesn't come a long when you clone up to a tag, which I admit confused the heck out of me at first, I didn't find any need to bring along the changeset with the tag in it.
Yes it can be done by post-clone/pull hooks, but there are a couple of crooks.
First, it only works for local repo, since you can't get the list of tags in a remote repo.
Second, dealing with clone/pull arguments and options is not trivial. (For clone I need to get the target repo, -r, -u, -U. For pull I need -r and -u.) I tried to use fancyopts, but it can't deal with global options, which are processed away in dispatch. I managed to hack dispatch to give me only the args and opts of a command, but it feels and looks ugly.
Using command wrapper would eliminate the second problem.
I hope one day hg will add an option to clone and pull to do it cleanly.