What is the correct way of running hg update in an incoming hook?
Is it:
[hooks]
incoming.foo = hg update
Or this
Or is there a more elegant way of doing this?
The FAQ makes this suggestion:
[hooks]
changegroup = hg update
This goes in .hg/hgrc on the remote repository
So, indeed, this is the simple and correct way of doing it. Your example used incoming, but that hook runs once for every single changeset. The changegroup hook is done once after all changes have been pulled in, so I think it may suit your needs better.
If you end up needing more control, you can create an in-process hook script to fulfill those needs. The Wiki has some good examples.
Related
In git, there is a common practice of removing push access to the upstream repository for teams which use a specific workflow. This can be accomplished with a simple command to change the configuration. This keeps developers from accidentally pushing up changes without the proper review process. It still allows users to pull the latest changes from that repository.
Is there a way to configure a local mercurial repository to stop it from being able to push to a remote [read-only] repository?
You have at least two ways: local and remote
Remote-repo type
On push-target add pretxnchangegroup hook, which reject pushes (all or some), easiest form
#!/bin/sh
echo 'No pushes here'
exit 1
Local type
Add alias, which redefine push into "something" without real push, but note the note in docs
It is possible to create aliases with the same names as existing
commands, which will then override the original definitions. This is
almost always a bad idea!
first: We use a github repository in the team for some projects.
I'm using scripts defined in the pre-commit hook directory, locally (works perfect for my commits).
What I need is for every user (collaborator) to use the hooks without using symlinks or asking them to put them on their home folders.
Is there a way to set them up so the users can't commit if the scripts don't exit 0?.
Thanks.
As Henrik alluded to, in the Enterprise version, there is such a thing as the pre-receive hook. It runs server side and so you would not need to install it on each collaborator's local machine. But you are using github.com actual, and they don't allow pre receive hooks , nor do I expect they plan to; allowing indivduals to run scripts on their server isn't likely in their business plan. So that likely won't help you unless you are in a position to go to the enterprise product
There are some remedies you do have, however, but it won't be equivalent. You can , for example, set a protected branch . You could thereby make it only you can check into that branch, and you of course would be using the local hook, every one else would be using a pull request.
Additionally, you could look into LGTM (Looks Good To Me) or similar automated pull request approval system. I don't believe the official server is up but the source code is there and it could be run by someone else. LGTM allows you to set a number of different conditions that would be closer to an equivalent to your pre-op hook.
Setting up such a system might well be more effort than it is worth to you, understandable; but it is do-able.
The main problem with using pre-commit hooks that come with git is that they are local to your repos and don't get pushed to github.com. I believe under the hood, those hooks aren't even transferred up to the repo on github, and that the pre-commit hook directory itself is not available like it is on the local copy of a git repo.
(I would say more on that architecture of the pre-commit hook dir except A. I am not sure if it is covered by NDA and B. I only saw the way it was on the Enterprise product, not github actual, and C. I don't know if the structure is still exactly the same)
I have a local development system where I have a Ubuntu-Server VM and I use eclipse in windows host. I develop in eclipse using Remote System Explorer & SSH. I want that whenever I save a file or do some changes in ubuntu-server's /var/www/site-folder it automatically commits and pushes the changes in my git repo. I did try the google but it wasn't much of a help. Any help is appreciated guys. Really wanna improve my workflow.
This sounds like something you'll have to script. If you save as much as I do (a lot), then you'll end up with a lot of commits. Unless you're careful about when you save, you'll probably end up with a messy history, unless you squash things later.
Are you sure that you want to commit and push automatically every time you save? It also matters whether or not you're pushing to your own private branch or repo.
Actually I think there are use cases where this /is/ a good idea. If you work on two different machines (even not simultaneously), for instance, you cannot share the Eclipse workspace. One simple way to overcome this is to put a bare git repository on a cloud server (dropbox, copy, one drive, etc) and push all work, completed or otherwise, to that everytime you close eclipse.
Will the repo be messy? Sure, but that's not the point.
I could find no easy hooks within Eclipse itself to automate this so I simply put an invocation of Eclipse in a script and finished off with:
git commit -a -m "WIP commit"
git push origin
You just have to watch out for newly-created files and remember to add those before you exit.
Is there a way in GitHub to change a commit message if I've committed with a message that has a typo or something dumb written in it?
I know you can do the ammend commit thing (which replaces the previous commit) from the CLI, but is there a way to just edit the commit message from the GitHub.com site interface?
If the problem commit is more than one commit ago, you have to fall back to interactive rebase. For example, if you notice a misspelling three commits ago, you would type something like this:
git rebase -i HEAD~4
Then rebase would open up your default editor with a view that looked something like this:
pick c5052cb Updated the workshop instructions
pick 6d6cd60 Upgraded to the plugin 0.6.1
pick c6d0921 Upgraded wrapper to Gradle 1.2
pick 7a111da Upgraded to 0.7 of the Liquibase Gradle Plugin.
# Rebase 097e6b2..7a111da onto 097e6b2
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
You'd want to edit the third line (the one referring to commit c6d0921) to start with the word "reword" instead of "pick." Once you save and exit from the editor, you'll find yourself right back in the editor with that commit's message in front of you. Correct your misspelling, save and exit, and all is well.
Note that doing this or doing a commit --ammend is dangerous business if you've already pushed these commits to an upstream repo. This is why there's no way to do this on GitHub.com directly. If you want to change commits you've already pushed, that's a separate matter entirely. :)
There isn't a way to do it directly on the site.
You could:
git commit --amend
git push --force origin master
One of the main reasons we don't want to allow people to do this on the site is because it'd change the entire structure of the commit (basically just think of this as changing the commit hash). This isn't a problem when it's only you, but for the sake of a community of people working with you, this is a problem because no one else will have that commit, and when they try to pull they run into issues.
This is the same as doing the ammend on the command line AFTER you've pushed, then force pushing to github.com. Usually a major no-no for workflows unless you take care with a lot of extra communication.
So i've made the switch from CVS to mercurial for my website.
The biggest issue I am having is that if i'm working on some files that I don't want to commit, I just save them.. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down.. It asks me to merge or rebase.. either of these options will cause me to lose my local changes that I have not committed.
I've read that I should clone the repository for each project on my local host and merge it into the live when it's ready to do so. This not only seems tedious, but also takes a long time as it's a large repository.
Are there better solutions to this?
I would have hoped that Mercurial would see that I haven't committed my changes (even though I have changed the file from what's on the server) so it'd just overlook the file.
Any input on this would be greatly appreciated. Thank you!
Also, i'm using the hg eclipse plugin to work on my files and push/pull from the server.
hg shelve is your friend here I think.
which comes from the shelve extention (maybe - see below)
from the overview:
The shelve extension provides the
shelve command to lets you choose
which parts of the changes in a
working directory you'd like to set
aside temporarily, at the granularity
of patch hunks. You can later restore
the shelved patch hunks using the
unshelve command.
The shelve extension has been adapted
from Mercurial's RecordExtension.
or maybe its the attic extension
This module deals with a set of
patches in the folder .hg/attic. At
any time you can shelve your current
working copy changes there or unshelve
a patch from the folder.
it seems to have the same syntax as the shelve extension, so I'm not certain which one I've used
I second #Sam's answer. However, if you prefer to use standard Mercurial, a simple workflow is to
save your working dir changes in a temporary file,
sync your working dir with a specific revision, then
push, pull, merge .. whatever you want to do and which requires a clean working copy, and
get back your changes from the temporary file into the working dir.
For instance:
$ hg diff > snapshot.patch # save your uncommited changes
$ hg up -C # get a clean working copy
$ hg pull # do things ..
$ hg merge # .. you need a clean ..
$ hg commit -m "merge" # .. working copy for
$ hg import snapshot.patch # get back your uncommited work
First, are you working from the commandline, or using something like Tortoise?
If you're working from the commandline, and you've done a pull, mercurial will not ask you to do anything, as it merely updates your local repository.
If you then do an hg update and have local changes, it should do what you're used to from CVS. It will update to the tip of the current branch, and attempt to merge your outstanding changes in. There are some caveats to that, so refer to the official docs at http://www.selenic.com/mercurial/hg.1.html#update.
Also, for temporarily storing changes, I would recommend MQ over shelve. Shelve only provides one storage area, whereas MQ provides as many as you need. MQ takes some getting used to, but worth the investment.