When I run commands such as hg log, I expect to see the output in a pager. I have configured my repository .hg\hgrc to use less:
...
[pager]
pager = C:\path\to\bin\less.exe
...
I have confirmed that less is correctly installed, as I am able to run it.
I have also confirmed with hg config --debug that this environment setting is correctly registered:
...
C:\path\to\repo/.hg/hgrc:23: pager.pager=C:\path\to\bin\less.exe
...
However, the output is instead dumped into terminal. This is a major nuisance, especially with hg log since the project I am working on has history dating back to 2001. Removing the configuration settings does not cause output to go through more, which according to Mercurial documentation should be the default Windows pager. (and yes, I have checked that more is installed)
If no pager is set in the user or repository configuration, Mercurial uses the environment variable $PAGER. If $PAGER is not set, pager.pager from the default or system configuration is used. If none of these are set, a default pager will be used, typically 'less' on Unix and 'more' on Windows.
Is it a known issue that Mercurial pager support on Windows is currently broken? If not, what steps can I take to make Mercurial recognize and use a pager? At this point I don't even care if it uses less as long as the output is sent to any pager.
Environment: Mercurial version 6.3.2 (installed with TortoiseHG) on Windows 11.
I have attempted to run hg commands through Command Prompt, Powershell, and Git Bash; none of them correctly use the pager configuration (or any other pager, e.g. more).
EDIT: in response to a comment below, here is the full output of hg --version --verbose:
Mercurial Distributed SCM (version 6.3.2)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2023 Olivia Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Enabled extensions:
This question does not resolve my issue as it uses the PagerExtension, which is outdated and unnecessary as of current Mercurial version. I have also tried the steps here to use the PagerExtension, to no avail.
TortoiseHG is slightly different than pure Mercurial in Windows, not due to code-changes, but (as it was discovered during last researches) due to py2exe limitations.
Pager support is one of such things: if you'll run hg version --debug you'll see warning about it
> hg version --debug
pager is unavailable with py2exe packaging
Mercurial Distributed SCM (version 6.3.2)
(see https://mercurial-scm.org for more information)
...
Workarounds
Use pure Mercurial in parallel with THG - install and put HG path in PATH after THG's
Because I'm lazy (as declared) I use hg log | bat -p -l log --pager "moar --no-linenumbers" with best viewer and pager at a time and even still don't overload hg login shell alias (use PowerShell history and expansion)
Related
Some years ago, Mercurial | TortoiseHG could exchange data bidirectionally easy with at least 2 Big Brothers:
Subversion, using HGSubversion
Git, using HG-Git
Current (6.0 versions of family) state - the ordinary users have none:
hg-subversion is broken (extension can't be loaded), bundled with THG (Mercurial ???) extension not updated since 2019 hgsubversion: 6a6ce9d9da35 2019-04-19 (extraction from my TortoiseHg\extension-versions.txt), external SVN-bindings exist only for Python 2.7 (while py3-movement inside Mercurial is live and active)
hg-git got some big troubles, starting from THG 4.9 (manual patching of library.zip was required), on 6 version the situation has gotten better (no patching), but still unsatisfactory for the common user - installing Python 2.7 (for single-user) and using pip isn't The Right Way (tm)
Are there any comments, additions, clarifications, recommendations on how to do it (if what I am doing is wrong)?
Addition after some testing: special verson tortoisehg-6.0hggit-x64.msi from Matt Harbison at least allow using hg-git with ssh-transport (not http yet) and can be recommended for every-day usage by ordinary user.
So, as a current maintainer of hg-git and former contributor to hgsubversion, I think I can provide some context here.
Regarding hgsubversion, the short answer that it is either dead or — at best — extremely dormant. Personally, I have not interacted with a Subversion repository in years, and that's a common experience. No-one has been sufficiently motivated to fix bugs, keep it working, and — last, but not least — make it work with Python 3.
For hg-git, a period of semi-dormant state meant that the TortoiseHg maintainers stopped bundling it. We now keep up with Mercurial releases, and I've requested that they reverse that decision. I believe they bundle Dulwich, but as I don't use Windows, I can't say for sure. That said, it's quite reasonable to want to use hg-git with TortoiseHg, and if you run into any specific issues, I'd suggest you file a bug with them — or perhaps add a comment to the bug I linked earlier.
Generally speaking, you should be able to use 0.10.x version of hg-git with most versions of TortoiseHg, as I believe they bundle Dulwich. In that case, enabling the extension should be as simple as:
hg clone -u 0.10.x http://foss.heptapod.net/mercurial/hg-git /path/to/repo
And then adding the following to your .hgrc:
[extensions]
hggit = /path/to/repo/hggit
Once TortoiseHg moves to Python 3.x, the default branch of hg-git will work with it again.
EDIT: I was wrong; they don't bundle Dulwich, it seems. On the bug for this, one of the maintainers posted a link to a packaged installer that includes hg-git & Dulwich. The next release, 6.1, should fix this. Please consider testing the installer, and report to the TortoiseHg maintainers whether it works as expected.
EDIT²: Please note that only SSH works with that installer, as they ran into some issues bundling urllib3, which is necessary for HTTP support.
TortoiseHG 6.2
Bundled hg-git works (at least with GitHub), but for now only for https:// repos:
old worked ssh-access failed with complaining about my keys
With the new keypair (still RSA) and PageAnt-x64 (for THG-x64) I got both access-methods in game
I'd like to install programs with conda in one particular conda environment and to be able to use the associated commands from all conda environments.
My goal is to allow students to install Mercurial (plus few Mercurial extensions and related utilities like Meld and TortoiseHg) on any platforms (especially Windows) with one simple command (or few simple commands), and of course without compilation.
Of course the hg command should be available in the terminal from any conda environments (anaconda prompt on Windows). The Mercurial packages cannot be installed in the base environment because Mercurial still works better in Python 2.7 (anyway, it wouldn't be clean).
Now Mercurial and the extensions we need can be installed on all platforms with something like:
conda create -n py27_mercurial -c conda-forge python=2.7 mercurial dulwich ipaddress
conda activate py27_mercurial
pip install hg-evolve hg-git
Working a bit with conda-forge and a conda meta-package, it won't be difficult to do that with one very simple command. Moreover, it should not be difficult to create conda packages for Meld and TortoiseHg.
From this stage, the hg command is available when the environment is activated (and it is very simple to install other Mercurial extensions). To make it available from other environment (and in the base environment), one need to append the path of the directory containing hg to the environment variable PATH or on Unix to create a symbolic link (I don't know Windows enough to know if something similar would work). Both solutions are not straightforward and the commands are not platform independent.
I didn't find a command to do something like this in conda but sometimes conda experts are able to do impressive things! What would be an elegant solution to this issue?
It would also be nice to create icons somewhere (in the Anaconda launcher?) for the graphical applications (Meld and TortoiseHg). Is it possible?
Edit: Conda applications
I discovered that there is a way to specify in the meta.yaml file that a package is an application: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#app-section
It may help to solve the issue.
Edit after a first answer based on a bash function:
Of course, I'm looking for a solution involving very small work (and understanding) for the users and with cross-platform commands.
Note that for Linux and Bash, one can just do:
CONDA_APP_DIR=$HOME/.local/bin/bin-conda-app/
mkdir -p $CONDA_APP_DIR
echo -e "\nexport PATH=\$PATH:$CONDA_APP_DIR\n" >> ~/.bashrc
ln -s $(which hg) $CONDA_APP_DIR/hg
No need to activate/deactivate the environment each time hg is used...
Of course, such solutions dependent of the system and the shell are not satisfactory. It should be possible to do such things with cross-platform conda-like commands (see https://github.com/conda/conda/issues/8556), something like
conda config --add channels conda-forge
conda install conda-app
conda-app install mercurial
Now, I just have to implement conda-app 🙂
One can always create a shell function/alias and shove it in their shell's runtime configuration file. For example, for your use case, I'd add the following in my ~/.bashrc:
hg() {
(conda activate py27_mercurial
command hg "$#"
_hg_exit_code=$?
conda deactivate
exit $_hg_exit_code)
}
Then, regardless of which environment you are in, you always run hg from the environment it was installed in. To make sure that this function is loaded for you shell in a new session, one can always take a look at the output for: type -a hg
I do this one-time-setup for all the tools (some are custom compiled) and have an alias/shell function for each. This way I can happily switch b/w environments without having to worry much.
The solution https://stackoverflow.com/a/55900964/1779806 is buggy for scripts using command hg ... and too inefficient for this case (installation of a command-line application). See https://github.com/conda/conda/issues/8556#issuecomment-488703716
I created a tiny Python package conda-app (https://pypi.org/project/conda-app/) to improve this situation.
This should now works on Unix systems (with Bash and Fish):
conda activate base
conda config --add channels conda-forge
pip install conda-app
conda-app install mercurial
It should not be difficult to improve conda-app to also support Windows.
For the time being, Windows users can install Mercurial and important extensions by installing TortoiseHG.
I upgraded to Tortoise 3.6.3 yesterday and now I am prompted every time I pull or push a repo. The keyring is set properly, and my user name is in the url.
Any ideas on what may be wrong? Did 3.6.3 break keyring?
Issue 4401 "mercurial_keyring always asks for user/password" from time of 3.6.2 closed as pure extension-specific and contains solution: don't use username in URL anymore
Here is what to put into .hg/hgrc:
[auth]
default.username=myname
default.prefix=http://myrepo
A good way to debug issues like this is to run merciural from the command line with the debug flag, as in:
hg pull --debug
This will clearly indicate if there are problems getting the repo, user name, and password.
UPDATE: A new version of TortoiseHG has been released (3.8.3 at the time of writing) and fixes this issue: upgrading to latest version should be enough.
I had this exact same problem and found the following investigation article to be quite helpful to better understand what't going on (I'm not the author, BTW).
To cut it short, it seems a bug of the mercurial_keyring extension v1.0.1, introduced in TortoiseHG 3.6.2, which also appears to be fixed in v1.1.1.
If you're into Python compiling, it should be possible to upgrade it manually into TortoiseHG by getting it from its official bitbucket repo, compile it and manually place it into TortoiseHG's /lib/library.zip file (backup it beforehand might be wise): if you're not, you have 2 options:
1) clone the bitbucket repo to your HDD and then configure your Mercurial installation to use the new version of that extension module by writing the following in your C:\Users\USERNAME\mercurial.ini file (which was what I did):
[extensions]
mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
(Notice: you might also have to put the path in your PATH or PYTHONPATH env variable, depending if you already have Python and/or Mercurial installed on your machine).
2) wait for the next TortoiseHG release that will contain the updated version.
I am using VCS checkout mode to agent side and also have defined the teamcity.hg.agent.path = c:\program files\mercurial\hg.exe in agent.properties file. Still VCS is not picking up this setting and giving me the following error:-
Test connection failed in Dev :: Stocks :: Build and Package. Cannot find mercurial executable at path 'hg'
Also have defined the path in windows environment variables. Mercurial is not installed on server machine. I have read in documentation that if you are using a agent side checkout then not required. Please guide what I am missing here.
thanks
According to the documentation, if you're using server side checkout, then you don't need to install mercurial on your agent.
But when you set up version control as a VCS root, you do need the TeamCity server to be able to talk to the mercurial server so it can do things like detect changes. The JetBrains documentation specifically says that if you're using a Mercurial VCS root:
Mercurial should be installed in the server machine, and, if
agent-side checkout is used, on the agents.
I have recently updated to eclipse juno. I have also updated mercurial to its latest version, but it is still giving me problems. The mercurial plugin tells :"Unsupported hg version:1.9.3. Expected is at least2.0.0." but its already updated(see pic).
If I try to commit, it automatically opens preferences window, which gives message :"Mercurial is not configured correctly.Run 'hg debuginstall' to analyse.".
When I do that, it says:"no username supplied". Then I run "hg -y debuginstall", which says, no problems were detected.
Everything that I mentioned is depicted in the picture.
Uncheck the option labelled Use default (built-in) Mercurial executable; then in the text box labelled Mercurial executable below, you can enter the full path to the hg.exe under your TortoiseHg 2.5 installation.
I got the same error when I installed Mercurial Eclipse Plugin. I find the configuration file "Mercurial.ini" in the mercurial installation folder. In my case, the path of that folder is "E:\eclipse\plugins\com.intland.hgbinary.win32_2.3.2\os\win32". Edit the configuration file with notepad and add the line "username = your-user-name" where your-user-name is free to choose. I hope it would help.