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 :)
Related
I'm sure we've all done that thing where you temporarily hot-wire part of your application while you test something. We really don't want to commit such changes though.
Usually I mark such lines with a comment reminding me not to commit this change. But is there some way I can program Mercurial itself to refuse to commit any line containing a certain text fragment? (Not the entire file, just the marked line.) Is there some extension or something that does that?
The answer is a clear 'No, but...' (or 'Yes, but...' - depends on how you see it).
If you always indicate WIP lines in the same manner, I recommend to write and install a (local) commit hook which will fail, if any such WIP lines are detected in the changeset.
See https://www.mercurial-scm.org/wiki/Hook and https://www.mercurial-scm.org/wiki/UsefulHooks
In order to commit only some hunks, you can make use of the record extension (it's a default extension, just needs enabling). It allows you to cherry-pick the hunks at commit time. But it will fail at cherry-picking if the WIP code and the 'actual' code are in the same hunk.
Contrary to (good and correct in terms of sense) platetmaker's answer I'll suggest another way:
Enable, learn and use MQ Extension (see also Tutorial page) or, as lightweight alternative, Shelve Extension
Store your WIP (modifications in working directory) as MQ-patches or shelves locally until they aren't finished
I have a utility script that will configure the local developer instance to mimic a specific production one - copy over the correct connection strings, client files, etc - thereby making it easy to investigate certain issues.
Because this is all done locally this changes files in the working directory. The first thing the script does therefore is print out a big fat warning to caution developers not to commit and revert changes when they are done. However it is possible to forget or miss this warning as cruft from my build system scrolls by and I wonder if its possible to go further.
Is it possible to do something to the hg repo so that a commit will be rejected and the developer would have to revert first?
I realize there are some variables to the question as far as revert what and commit what but given that I'm not even sure that this is possible, I am willing to take close-with-caveats for an answer.
This is exactly what hooks are for. You would need a precommit hook on every repo or possibly the pretxnchangegroup.
By creating a precommit hook (script) that checks for a specific file or a specific change, you can fail the commit and print out whatever warning you need. The return value of the script indicates to mercurial if the transaction is valid or not.
Use the following generic sample to check for the presence of certain files that would be committed, before accepting or rejecting the changesets.
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.
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).
I have a local mercurial repository with some site-specific changes in it. What I would like to do is set a couple files to be un-commitable so that they aren't automatically committed when I do an hg commit with no arguments.
Right now, I'm doing complicated things with mq and guards to achieve this, pushing and popping and selecting guards to prevent my changes (which are checked into an mq patch) from getting committed.
Is there an easier way to do this? I'm sick of reading the help for all the mq commands every time I want to commit a change that doesn't include my site-specific changes.
I would put those files in .hgignore and commit a "sample" form of those files so that they could be easily recreated for a new site when someone checks out your code.
I know that bazaar has shelve and unshelve commands to push and pop changes you don't want included in a commit. I think it's pretty likely that Mercurial has similar commands.
I'm curious why you can't have another repo checked out with those specific changes, and then transplant/pull/patch to it when you need to update stuff. Then you'd be primarily working from the original repo, and it's not like you'd be wasting space since hg uses links. I commonly have two+ versions checked out so I can work on a number of updates then merge them together.