Is there any simple way to prevent commits to a repository if it has dirty subrepos?
It's really annoying when a subrepo is accidentally committed along with a parent repository.
I don't know where your line for simple lands but you could do a hook like this:
for subrepo in $(find $(hg root) -type d -name .hg) ; do
if [ "$(hg --repository ${subrepo$$.hg} status -mard)" != "" ] ; then
echo Uncommitted subrepo changes in ${subrepo%%.hg}
exit 1
fi
done
Save that in something like ~/bin/dirtysubrepos and then add this to your ~/.hgrc:
[hooks]
precommit.dirtysuprepos = ~/bin/dirtysubrepos
Disclaimer: This code has never been typed anywhere except this textbox, so it almost certainly has syntax bugs.
I can't comment on Ry4an's answer for some reason (no "Add comment" link for me to click on), but there's a minor typo in his answer: there's an ${subrepo$$.hg} that should be ${subrepo%%.hg}.
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.
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 ;)]
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.
I've got a Mercurial repo set up like this, with a subrepo inside another subrepo:
Root
.hg
.hgsub
.hgsubstate
Nested
.hg
.hgsub
.hgsubstate
foo.txt
FurtherNested
.hg
bar.txt
If I change foo.txt and bar.txt and commit from inside Root then all is well and all the nested subrepos commit. However if I only change bar.txt and commit from Root then Hg thinks nothing is changed. I have to commit from inside Nested to get the FurtherNested changes to commit when there are only changes in FurtherNested. It seems that in order for nested subrepos to work, each nested level has to contain changes in order for the recursion to work.
Nothing I read in the Mercurial docs on subrepos seemed to imply that subrepo commits would only propagate if there were changes. In fact it says the opposite:
When we commit, Mercurial will attempt
to recursively commit in all defined
subrepos...
So my question is, is this to be expected or is something broken or just not done yet (Mercurial 1.5.4 on Windows)?
Looks to me like this is just something that's broken. The relevant source code (in subrepo.py) doesn't seem to recurse into subsubrepos, viz:
def dirty(self):
r = self._state[1]
if r == '':
return True
w = self._repo[None]
if w.p1() != self._repo[r]: # version checked out change
return True
return w.dirty() # working directory changed
Probably wouldn't be too hard to fix, though I don't know the code intimately enough yet. It would probably be worthwhile posting on the Mercurial mailing list and/or filing a bug. I doubt Matt and Benoit are reading this, but they definitely do read everything posted there.