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
Related
I need to set up Mercurial HG in order to always take local version of a file that matches in a specific folder.
EG: when conflict on /**/dist/ always take local
This because I need to commit some built files.
Thanks in advance
EDIT:
I need to commit some files generated by some processors (libsass, webpack), it depends on a temporary unavailability of my build-system. So, I removed these files from the hgignore. Now, the problem that I'm having is on Mercurial conflicts on these generated files. I want automate the merge-resolving using the local version of these files. similar to: How to keep the local file or the remote file during merge using Git and the command line? but for Mercurial HG
You can put a merge-pattern in your ~/.hgrc or .hg/hgrc to specify the default tool for a merge for a given file:
[merge-patterns]
**/dist/* = :local
The :local merge tool will prioritize the local version. See hg help merge-tools for a full list of internal merge tools. Note that using the --tool option during a merge will override this choice; however, setting the ui.merge option to define your default merge tool will not.
The **/dist/* pattern may or may not be what you need. Please adjust it to your needs (and note that regular expression patterns are also available for additional flexibility if required).
Alternatively, you can also automatically resolve these files after the merge, e.g. with:
hg resolve --tool :local $(hg files -I '**/dist/*')
Or, if the list of files is too large to fit on the command line:
hg files -0 -I '**/dist/*' | xargs -0 hg resolve --tool :local
I've just started using Meld. I'm using its Version Control Diff feature and its working well, except that it doesn't seem to use the .hgignore file.
The tree I'm working in is huge, but I only mercurial-track a small portion, so Meld is taking a loong time to scan the entire tree, 90% of which I could care less about.
I'm using Meld 1.6.0, which doesn't appear to allow the user to manually select the VC type, so I'm forced to start the compare in the directory containing the .hg sub-dir.
Is there a way to get Meld to use the .hgignore file or perhaps override Meld's default VC choice?
I think you should do "the other way around", that is:
configure mercurial to use meld as its "external diff" tool, utilizing "extdiff" extension.
NOTE: All of the above has been tested in UNIX-like environment
in ~/.hgrc enable "extdiff" extension by adding to [extensions] section:
[extensions]
extdiff =
add this below:
[extdiff]
cmd.meld = # if meld is not in your path, you may need to type in here the absolute path to the script
Save ~/.hgrc file.
Now, Then a new hg subcommand shall be available to you.
Enter the hg repo folder, in terminal:
user#machine:~$ cd myrepo
user#machine:~/myrepo$ hg meld
That would spawn meld properly, respectful to .hgignore, mercurial respects itself )
For GUI trickery, you may hook this up to context menus of your favourite file manager:
1. Linux: you may to dance with the Shaman's drum a bit more, but TortoiseHg respects extdiff extension.
1. Windows: TortoiseHg does this automagically
1. Mac: no idea how to do this to Finder :), maybe AppleScripting will be needed here.
Regards.
I version controlled a project settings folder a couple months back on my default branch, and then over time created many branches off default. Now I've decided that I'd rather not have the project settings folder version controlled as it creates a lot of problems when switching between branches.
So I've hg forget'd this project settings folder which lets me keep the files on my local machine but removes them mercurial. However, when switching from one of the old branches which still have this folder versioned back to the default branch it actually removes the files from the local machine, which is bad.
How do I prevent that?
The folder is also in .hgignore on default now.
It's impossible to do.
But the common practice is to keep config.ini.dist in your repository and build environment-specific config by some build-system right after you check source code out.
The standard way to deal with this is to version control a template config file and ignore the real config file. The real config file can then include the template file, or maybe the template file is copied over once in a while.
The underlying reason for your problems is that running:
$ hg forget config.ini
is exactly the same as running:
$ hg remove config.ini
$ hg cat config.ini > config.ini
The forget command leaves the file behind in your working directory, but what you commit is still a file removal. This means that afterwards, Mercurial cannot distinguish between "file was forgotten" and "file was removed" — only the removal is committed, so the two commands look exactly the same.
My understanding: Mercurial has three levels of config files: one shared by all users (installation level), an overriding one for each user (user level) and an overriding one for each repository (repo level).
The HGRCPATH environment variable appears to override the second level, the one found in the users/<user> directory in Windows.
However in TortoiseHG's settings screen, it refers to (and allows direct edit of) the user level config file in the users/<user> directory, even when overridden by HGRCPATH. Quick experimentation has shown that TortoiseHG indeed uses the one set by HGRCPATH, not the one it indicates.
Is this a bug with Tortoise or is my understanding of HGRCPATH flawed?
Yes, this must be a flaw in TortoiseHg. The hg help environment help text says that HGRCPATH is used to override the default search path for configuration files. This includes ~/.hgrc and lets you quickly disable your user settings:
$ HGRCPATH= hg log # <- only read .hg/hgrc, ignore all other config files
You cannot make Mercurial skip reading .hg/hgrc.
The description in the Mercurial manpage makes it sound like if HGRCPATH is set then both the system-wide file (/etc/mercurial/hgrc on linux) and per-user file are ignored, but that the $(hg root)/.hg/hgrc file is still consulted. That's been my experience outside of tortoisehg.
I wouldn't expect the tortoisehg GUI to not-show the hgrc commands its not invoking, just to not take in their settings. Is that what you're seeing?
http://www.selenic.com/mercurial/hg.1.html
Is there a way to make Mercurial treat a file as if it matches the source control copy even if it has been altered? This was an easy trick to do with Team Foundation Server / Source Safe where just making the file writable through explorer would make those systems ignore that file on check ins.
(Note this is a file that is checked in and has a value but is sometimes different per developer, think connection strings)
Define aliases in your hgrc for the commit command that excludes the file you don't want to track in the commit.
[alias]
xcommit=commit --exclude path/to/file
xstatus=status --exclude path/to/file
The hgrc reference says that you can define aliases with the same name as existing commands; I found that it worked for hg status but not for hg commit.
I found that .hgignore doesn't obey entries for files that are already in the repository so that's not an option.