I never use those .orig files, and I hate cleaning them up manually. Is there a way to configure hg revert to use the --no-backups option by default? I can't find it in the Mercurial manual
Using a shell alias is possible but isn't desirable.
You can create an alias in your config file.
More details on the config file at http://www.selenic.com/mercurial/hgrc.5.html
Read the manual myself, and it looks like its changed somewhat since the last time I read it. I was going to suggest using defaults, but it appears that has been deprecated. The recommendation is to use aliases.
It appears an alias CAN override a built-in command, but obviously they don't recommend it.
So, you could do
[alias]
revert = revert --no-backup
but the recommendation would be to create a new command for yourself
Actually, the best way is to include the following two lines in your .hgrc file:
[defaults]
revert = --no-backup
Related
Can I check the version of mercurial before setting a particular setting in my ~/.hgrc file? For example, I'd like to enable an extension (say the shelve extension), but only if the hg version is a particular version (say 2.8 or later). This is particularly useful when one's home directory is shared (think nfs) over many machines that have various versions of hg installed.
That's an interesting one. There are no conditionals in the hgrc format, but there are variable expansions in include lines, so you could put this in your .bash_profile:
HG_VERSION=$(python -c 'from mercurial.__version__ import version; print version')
and then in your ~/.hgrc have something like:
%include ~/.hgrc-$HG_VERSION
which would include a file like, ~/.hgrc-2.6.2
To avoid errors you need a possibly empty file for each version you run, and you could use bash-fu to trim off the minor version for a little flexibility. It still won't get you greater-than functionality, though.
The more normal way to do this is to use the include mechanism to include host or OS specific hgrc files like:
%include ~/.hgrc-$HOST
which lets you add in bits that are run only on certain hosts.
You could also have hg read a different hgrc file by checking the version of hg in .bashrc and setting the HGRCPATH Variable accordingly; See Mercurial .hgrc file
I have a file default.config in the root of my repository. I tweaked it for my own setup, and I do not want to commit it. Ever. What are my options other than commit -X "^default\.config$"?
I added ^default\.config$ to .hgignore, but it still shows up in the output of hg status -mard.
Edit: maybe it's possible to do this with Mercurial Queues. If I keep all my local config changes in a single patch, then I just have to remember to pop it before committing. Just thinking out loud...
Follow these steps:
Copy the file somewhere outside your working directory
Remove the file with hg rm default.config and commit the changes
Copy back your file to the working directory
As a good practice you can add a file called default.config.template or something which is committed to the repository. This file holds some kind of default values or comments on how to use it and other users/developers can copy this file to default.config if they're using your project.
Akluth has the correct answer: commit a template file to your repository and then copy that to the real name in each working copy. If the config file supports it, then use an include directive to load the template file from the real config file. Something like
// default.config
//
// load defaults from versioned template file
#include "default.config.template"
// override defaults with my settings
db_hostname = localhost
db_user = me
An alternative is to use -X with every command, as you suggest. There is an exclude extension that implements this idea. Remember to read the caveats — it doesn't work when merging because you cannot exclude files when committing a merge. The extension would need to be extended to handle that case, probably by shelving change before the merge and unshelving it afterwards.
This suggests another stragety, similar to using MQ as you suggest: use the new shelve extension in a set of pre- and post- hooks to shelve/unshelve the file before/after each operation. I think that could work, though I haven't tried it in real life.
Say I type hg add in Mercurial, and there a bunch of untracked files in my working directory that are not ignored. What is the easiest way to un-add all those files without explicitly typing the name of each file?
Can I just un-add them all with one command?
Preface
You must always ask questions, which contain as much information as possible. Because now your question, depending from some conditions, may have totally different answers.
Case One - no local modifications in already versioned files, only added (and not committed) files
hg revert will return your working directory to the state after the last commit, undoing all changes it it.
Case One - local edits, which you want to save and occasionally added files
Read about filesets in Mercurial.
Use fileset in the hg forget command, something like hg forget "set:added()".
Use hg revert or hg forget on the files (both do the same for a file you ran hg add on). To avoid typing out the filenames, you can use a fileset like this:
$ hg revert "set:added()"
This will revert the file back to how it looked in the working copy parent revision, i.e., it will become unknown again.
hg revert -r .^ path-to-file will revert the commit from the commit-set.
then commit and submit (if using jelly fish) and you'll see the files removed from the changeset. I don't know why .^ works yet, but somebody will probably know.
You could always just re-clone your repository and then replace (delete existing and then copy new) the .hg directory in your working folder with the one from the fresh clone... (assuming you have no pending commits..)
I have configured hg log in ~/.hgrc to only list commits from the current branch by default:
[defaults]
log = --branch .
However, occasionally I'd like to really see commits from all branches. Is there a way to tell hg log when invoked form the command line to not use the configured defaults but fall back to the built-in behavior? As a brute-force solution ignoring ~/.hgrc altogether for this particular invocation of hg log would be fine for me.
I'm aware that defaults are deprecated in favor of aliases, but aliases cannot be created with the same names as existing commands, which is what I want in order to not have to learn new command names, esp. when ~/.hgrc settings are to be shared by multiple developers.
Edit: Not being able to create aliases with the same names as existing commands was a regression that has been fixed.
You should be able to use --config to override the setting in your .hgrc:
hg --config defaults.log= log
From the man page:
--config set/override config option (use 'section.name=value')
I have gone through the bug reports on the Mercurial website and cannot find any workarounds for this, the response being a blanket "this is deprecated".
Personally, not learning the commands to me is not a valid reason for not migrating away from default command values. A possible alternative would be to move away from per-repository settings and have some settings at the user level, so you can set your own defaults / aliases.
Defaults are now deprecated, so you should likely remove this and specify the arguments each time. Confirmed in the documentation:
https://www.mercurial-scm.org/wiki/Defaults
(defaults are deprecated. Don't use them. Use aliases instead)
Try:
[alias]
blog = log --branch
Usage:
hg blog <branch name>
hg blog default
I know I'm resurrecting an old question here, but this statement
aliases cannot be created with the same names as existing commands
is incorrect.
In your .hgrc file in the [alias] section, you can, for example, have:
[alias]
add = add --dry-run
This will make the add command always do a dry-run, instead of actually recursively adding all unknown files in the repository.
It seems the best solution to my use-case indeed it to temporarily ignore the ~/.hgrc file altogether. This can be done by setting HGRCPATH to an empty string, which causes Mercurial to only read the .hg/hgrc file from the current repository:
HGRCPATH="" hg log
There are two project in which I collaborate, they live in different servers, A and B.
While A has the hg program in /opt/mercurial/bin/hg, B has it in /usr/local/bin/hg.
When I want to pull/push changes to either remote, I have to manually modify .hgrcfile in order for the option remotecmdto point to the right location of hg.
I would like to know if it is possible to setup different remotecmdpaths for different remotes so that I don't have to manually change the path of the hgprogram everytime I need to do some remote operation.
I saw this question: Setup platform-dependent hgrc but it seemed to me that there should be a more native (something like a built-in setting) way to do this. So far I haven't been able to find it, so any help will be welcome :)
Thanks!
Ideally you just get the hg binary into your $PATH on both servers and you don't have to think about it anymore. That can be done in the system's /etc/profile or in your .ssh/enviironment on that remote server. Most people never even need to think about remotecmd.
If they're separate projects (or even separate clones locally of the same project) you can set the remotecmd in the .hg/hgrc file within each repository -- settings don't just have to be in your ~/hgrc file.
Also be aware that --remotecmd is available as a command line option for push and pull, so you could use that and even combine it with something like:
[alias]
pusha = push --remotecmd /opt/mercurial/bin/hg
and then you can just do hg pusha
Really though, just try to get hg into your path like everyone else does.