New versions of mercurial will apply colors to the output of most commands and will pipe commands with long output to a pager. How do I restore the old behavior to not color output and never use a pager?
Add the following to your .hgrc:
[ui]
color = never
paginate = never
When working with commandline, you can also add parameters or options to your commands. This is however not permanent. The hg --help --verbose reveals:
--color TYPE when to colorize (boolean, always, auto, never, or debug)
--pager TYPE when to paginate (boolean, always, auto, or never)
(default: auto)
So the next command disables your pager and does not show any colors:
hg incoming --pager never --color never
Related
I use kdiff3 on Windows as the visual merge tool for TortoiseHG / Mercurial.
Often when doing a merge or rebase it will show a dialog like this:
Another variation is that the two files being merged were "binary equal".
Since these messages are basically saying that there is no conflicts / nothing to do, I'd like to suppress them - is that possible?
I don't see anything pertinent in the kdiff3 command line options.
Although having a bit misleading name, --auto option does what you want.
From the documentation:
--auto No GUI if all conflicts are auto-solvable. (Needs -o file)
This help text can also be accessing from the command line with kdiff3 --help.
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
Mercurial's pager extension doesn't use the pager for hg status, is this a bug?
Also, when using hg glog -p, the pager is used, but this doesn't conform to the guide: "If no pager is set, the pager extension uses the environment variable $PAGER. If neither pager.pager, nor $PAGER is set, no pager is used." I have no $PAGER set.
Please see hg help pager:
pager extension - browse command output with an external pager
[...]
Below is the default list of commands to be paged:
[pager]
attend = annotate, cat, diff, export, glog, log, qdiff
Setting pager.attend to an empty value will cause all commands to be paged.
[...]
So it's documented behavior: the status command is not paged by default.
I'm looking for a way to set .hgrc configuration items without actually editing the text file. I'm trying to standardize the setup of the hgrc across multiple developers and I would like a command like
hg --config ui.username=foo
but which also saves that config change into the hgrc file.
It seems like this should be something that should be supported directly in the vanilla hg command, but I can't find it anywhere.
Someone -- either you or Mercurial -- will have to edit the configuration file if you want the config change to be saved :-)
And if you can call Mercurial with
hg --config ui.username=foo
then you should also be able to do
echo '[ui]' >> ~/.hgrc
echo 'username = foo' >> ~/.hgrc
which will save the config change, not matter how the ~/.hgrc file happens to look like (it is okay to have multiple [ui] sections).
Mercurial 3.0 and later has the hg config --edit command that opens an editor with the user config file. Still not quite what you're asking for, but at least this makes it easier to edit the file interactively.
This form:
hg --config ui.username=foo
Doesn't save anything. It sets the value for just the one run.
Also you can use /etc/mercurial/hgrc for system wide settings if that helps anything.
There is an extension that helps with this, https://bitbucket.org/alu/hgconfig/wiki/Home
After installing that hgext, you can do things like this.
% hg showconfig paths
paths.default=ssh://hg#bitbucket.org/alu/hgconfig
% hg config paths.upstream $(hg showconfig paths.default)
% hg config paths.default $(hg showconfig paths.default | sed 's|/alu/|/nassrat/|')
% hg showconfig paths
paths.default=ssh://hg#bitbucket.org/nassrat/hgconfig
paths.upstream=ssh://hg#bitbucket.org/alu/hgconfig
The only gotcha is this overrides the builtin config command, you can either tweak the code to change the command name, or live with it. Fortunately, it probably would not matter if your use case is simply to set and get specific configs.
When I commit something in Mercurial like this:
hg commit -m "username question"
I see this output:
No username found, using 'WindowsVistaAdmin#ChunkyMonkey' instead
ChunkyMonkey is my Windows machine name and obviously WindowsVistaAdmin is the user that I am signed in as on this machine.
How can I set the username to something more respectable, or, at least, more concise?
In your ~/.hgrc (*nix) or mercurial.ini (Windows) file:
[ui]
username = First Last <email#address.com>
(mercurial.ini is in C:\Documents and Settings\[username]\ for XP and lower, C:\Users\[username]\ for Vista and higher. You can also run hgtk userconfig if you have TortoiseHg installed and do it that way.)
you can specify your username on the command line directly if you want to using --config. eg
hg --config ui.username=frymaster -m "comment here" commit
in fact, you can override anything in your .hgrc with this command. just look at your .hgrc and note the format:
[section]
key=val
that translates directly to
hg --config section.key=val
Information from here:
Setting up a username
When you try to run hg commit for the
first time, it is not guaranteed to
succeed. Mercurial records your name
and address with each change that you
commit, so that you and others will
later be able to tell who made each
change. Mercurial tries to
automatically figure out a sensible
username to commit the change with. It
will attempt each of the following
methods, in order:
If you specify a -u option to the hg commit command on the command
line, followed by a username, this is
always given the highest precedence.
If you have set the HGUSER environment variable, this is checked
next.
If you create a file in your home directory called .hgrc, with a
username entry, that will be used
next. To see what the contents of this
file should look like, refer to the
section called “Creating a Mercurial
configuration file” below.
If you have set the EMAIL environment variable, this will be
used next.
Mercurial will query your system to find out your local user name and
host name, and construct a username
from these components. Since this
often results in a username that is
not very useful, it will print a
warning if it has to do this.
If all of these mechanisms fail,
Mercurial will fail, printing an error
message. In this case, it will not let
you commit until you set up a
username.
You should think of the HGUSER
environment variable and the -u option
to the hg commit command as ways to
override Mercurial's default selection
of username. For normal use, the
simplest and most robust way to set a
username for yourself is by creating a
.hgrc file; see below for details.
Here is how my windows /users/xxx/mercurial.ini looks. I don't have to enter username or passwords for anything. Looks like it might be repo specific. I have tortoiseHG installed, not sure if that makes any difference.
[ui]
username=mbroekhuis
[auth]
repo.prefix=http://myrepo
repo.username=mbroekhuis
repo.password=secret
For anyone trying to use HG workbench
settings
user global settings
Edit File
Save