If I do a commit in Mercurial and then realise I haven't added enough information to the commit message, is there a way to just add another message or note without commiting anything else? What is the best way to get that extra info in there?
I realise I can sometimes rollback and commit again but that is not always possible. I don't want to rewrite history either, I just want to add information.
Unless you're willing to get into editing history using MQ or histedit (and in Mercurial that's not usual practice) or it was the latest commit (rollback) then you need to commit something else to be able to add another changeset with a different commit message.
Mercurial is built around the concept of an "immutable history" and it intentionally restricts tools that let you alter the past.
If this was your last commit then you could rollback and commit again (with the new message).
Related
I tried hg commit --amend it says:
abort: cannot amend public changesets
I don't want to rollback as it's pushed and partly reviewed already
There is no way other than rewriting the history, with the risk that other people might already haved pulled your changes.
Actually hg rollback is for undoing a change that has already been committed but not pushed yet.
While hg backout is for performing an inverse operation (but leaving the one you pushed) to come back to the previous state; which is not really what you would like.
I suggest to leave it as is. If you have access to the server, it would be possible to change the repository history but this is not advised.
As I understand it, you can't really fix a comment in Hg. So what I would like to do instead is re-push the exact same changes (or at least "touch" the same files and commit & push again).
The reason this is necessary is because we have a bug tracking and build system that relies on specific comment patterns, and we need to make sure the right files get included in the build, but if I forget to update the bug # in my comment from my last commit, and I accidentally commit and push it under the wrong # because i'm overzealous, how can I re-push those same files again without manually going into each one and adding a space or line break just to create a diff?
To clarify, I can't "rollback" or something; it's already been pushed with the wrong message.
As far as I know, current Mercurial features provide no support for this. After the changeset has been pushed, there's little you can do to un-push it, besides stripping it from the server repo and any other developer's repo.
I guess you you should ask those who set up this workflow in your shop; they should've come up with some exception handlers for it.
We usually just ignore issues like this, and close the bug by hand, making sure the bug links to the correct changeset. If the changeset is really messed up (usually this means bad changes, not a malformed commit message), we resort to stripping.
Since your change has already been pushed you can't use a simple fix, like "hg commit --amend", but you can do something similar. Basically, the following commands re-do the commit with Mercurial's help:
CSET=...the changeset to re-do...
hg up -r "p1($CSET)" # Update the working directory to the parent revision
hg log -r "$CSET" -p > changes.patch
hg import --no-commit changes.patch
hg commit # And use the appropriate commit message.
Then, merge and push.
The only way that I could think of doing this is to commit two more changes, one would be an hg backout of the incorrect revision and the other would be an hg backout of that revision with the corrected comment.
I don't like that idea though and wouldn't recommend it if there was any way to fix the problem in your bug tracking system.
we're moving from Subversion to Mercurial now. In Subversion there was possibility to add custom column into log (e.g. bug id) and force user to fill this column on every commit.
Is it possible to implement such feature in Mercurial?
Yes it's possible.
But before you go and do that, why isn't it enough to require bug fix commit messages to uphold to a certain pattern?
i.e. util: rename the util.localpath that uses url to urllocalpath (issue2875) (taken from Mercurial's repo)
Then you can install a hook on your central repository that scans incoming commit messages, and does whatever is needed when that pattern is found.
Furthermore, why would you want to force this on every commit? Is this for a QA team that should only commit bug fixes? If that's the case, a pre-commit hook that greps the commit message for the pattern sounds appropriate.
If you still want the extra field: when Mercurial commits something, it is possible to pass it a dictionary of strings, which you can fill with anything. See the transplant extension on how you might do that. You would also need to wrap the commit command and add a new command line option to it.
But I strongly suggest you think twice before doing this, because aside from the time consuming work involved in coding, testing (and maintaining this between Mercurial releases), you would also need to ensure that it is deployed on every environment where Mercurial is used.
My boss is constantly complaining about the need to commit a merge (-1 head type of situation). Are there any settings in tortoise that tell it to automatically commit after a merge?
I can see reasons why this is not a good idea (events where you merge items inappropriate and wish to undo it) but my boss also countered that you can just rollback or revert in such situation. Thoughts?
You can have a look to the fetch extension.
According to http://tortoisehg.bitbucket.io/manual/2.9/sync.html Tortoise HG supports the fetch extension if it is enabled.
However, you will have to enable the extension in every hgrc file manually, there's no way to enable an extension automatically trough the repository.
Concerning the potential problems, like your boss said, you can always rollback if something went wrong. So if your boss requires this extension, you can please him without fear :)
As described in: http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html I thought I could write a small hook which rejects checkins with malformed commit messages. Thats no problem, the issue I encounter is the following work flow:
If a developer makes let's say 10 local commits, some of them are malformed, and then pushes them to the central repository all will be rejected, but he is unable to edit the old commit messages since rollback will work only once..
How do you solve this?
Using the HistEdit extension, you can change the commit message locally, then push back the whole changes in the main repository.
I suppose you can't mandate developers to use the same precommit hook to check commit messages, because it's not a centrally-managed project?
An alternative to #gizmo's answer is to let developers use MQ and mandate code review before pushing (or better, someone pulling from them). Then if reviewers (or some review scripts) spot the malformed messages, the developer can use qrefresh to change the message.
You need to be careful about a couple of things in that workflow, though:
NEVER EVER push/pull unfinished patch, even though qfinish does not change the hash. It's just too easy to screw up.
Make sure developer qcommit every time before sending things out for review, otherwise you won't know if s/he slips in other changes in the next iteration (not that s/he would, but s/he could).