I added the convert extension (with no path) to my /home/user/.hgrc file, but it is not working:
$ hg convert source_r56 source_r56_fixed --filemap exclude.filemap
hg: unknown command 'convert'
'convert' is provided by the following extension:
convert import revisions from foreign VCS repositories into Mercurial
use "hg help extensions" for information on enabling extensions
I ran "hg help extensions" and realized that none of the enabled extensions in the file are showing as enabled.
I tried setting it in the source_r56/.hg/hgrc as well to no avail.
Update:
$ cat ~/.hgrc
[ui]
username = jetimms <jetimms#jetimms>
verbose = True
[extentions]
convert =
progress =
rebase =
[alias]
ssh = ssh -C
$ cat ./.hg/hgrc
[paths]
default = /home/jetimms/source
[extentions]
convert =
$
(BTW: source_r56 was cloned from a repository called "source".)
Perhaps to better answer the question about whether I am having the same problems with other extensions, I have included part of the results from "hg help extensions" regarding disabled extensions. Here I only note the ones listed above in the the ~/.hgrc. As noted in the comments, I have not used any other extensions.
$ hg help extensions
Using additional features
...
disabled extensions:
...
convert import revisions from foreign VCS repositories into Mercurial
...
progress show progress bars for some actions
...
rebase command to move sets of revisions to a different ancestor
$
You mispelled the word extensions in your .hgrc. Change [extentions] to [extensions] and you're set.
Related
Following the tutorial at https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html I added the following to my mercurial.ini file:
[extensions]
...
evolve =
[experimental]
evolution = all
Yet when I go to the command line and try it out:
# hg topic
hg: unknown command 'topic'
(did you mean pick?)
# hg topics
hg: unknown command 'topics'
(use 'hg help' for a list of commands)
That's all I get.
(hg evolve does work, however.)
I've searched but can't find any other documentation on either how to enable it, or if maybe it just isn't in the regular releases yet. But from other posts here & elsewhere, it does seem that people are using it. Although it is not listed in https://www.mercurial-scm.org/wiki/UsingExtensions.
What do I need to do to enable it?
My version of hg is the latest:
# hg --version
Mercurial Distributed SCM (version 5.6.1)
The tutorial is incorrect (out of date?)
You have to add the following to the Mercurial configuration file:
[extensions]
evolve =
topic =
I eventually spotted this at https://heptapod.net/pages/quick-start-guide.html.
I needed to provide paths to make it work on my system:
[extensions]
evolve = C:\Program Files\Python39\Lib\site-packages\hgext3rd\evolve
topic = C:\Program Files\Python39\Lib\site-packages\hgext3rd\topic
I would like to have Mercurial list all tracked files in the repo that are supposed to be symlinks. I can get a list of tracked symlinks that are symlinks in the working copy with hg files "set:symlink()", but that doesn't capture the tracked symlinks that aren't symlinks in the working copy.
What I want instead is a command that looks at the tracked file's properties in the manifest and tells me if the symlink bit is set. I've tried to use hg manifest -v, which the documentation says will "print file permissions, symlink and executable bits". I've tried that, but the symlinks are indistinguishable from non-link files whose executable bit is set. I get lots of:
755 * path/to/file
If I try to use the leading markers (hg manifest -v | grep '755 *'), the files I want are listed, but I also get lots of false positives.
Background: Adding and committing symbolic links seems to work for us, but Mercurial is refusing to create the symlinks when someone else pulls those changesets. I understand why Mercurial is refusing: we run afoul of an undocumented rule. So now we end up with files where the symlinks are supposed to be, and the content of the file is the path to which the symlink is supposed to point. If I can get Mercurial to tell me which files are supposed to be symlinks, I can easily replace the files with the appropriate links.
Thank you!
Edit: In my repository, the symlinks had not been committed properly due to a bug in the client, which is why hg manifest -v wasn't showing the committed files as links.
I've learned a few things, and I wasn't asking the right question, but let's get the close-enough answer out of the way first:
hg manifest -v | grep ' # '
Caveat: I will guess that it's possible for manifest to put multiple symbols between the permissions number and the path, so ' # ' as the grep expression may not work perfectly if you have an exotic set of bits on a file. I needed the spaces around the # because our repository has many files with # in their names.
The rest of the story: After some experimentation, I was able to determine that a particular mercurial GUI (SourceTree) wasn't committing new symlinks correctly, which turned out to be a longstanding issue with the Mac version. I created a new repo (hg init) and added/committed one target file and one symlink (Link\link.txt) with command-line hg. I then added/committed a second symlink (Link\STlink.txt) with SourceTree. hg manifest -v shows that the links were not treated the same by the different clients:
755 * Link/STlink.txt
644 # Link/link.txt
644 Target/target.txt
If I clone that repo, even with SourceTree, the Link/link.txt symlink is reproduced faithfully, but the Link\STlink.txt link is not. So the real fix for me is to replace all of the files with links and commit again from the command line and to try to remember not to use SourceTree to commit new symlinks again in the future.
To assess which files changed from symlink to 'normal files', you could try to throw some bash at it and compare the output of the fileset of the modified and unmodified versions. Maybe something like
diff <(hg files "set:symlink()" -r.) <(hg files "set:symlink()")
Example:
In a repository where eeg-link was added, foo22-link changed to a normal file and foo edited (and foo-link kept pointing at it):
$ hg diff
diff --git a/eeg-link b/eeg-link
new file mode 120000
--- /dev/null
+++ b/eeg-link
## -0,0 +1,1 ##
+eeg
\ No newline at end of file
diff --git a/foo b/foo
--- a/foo
+++ b/foo
## -1,2 +1,3 ##
foo is boo!
And this change, too!
+And even this.
diff --git a/foo22-link b/foo22-link
old mode 120000
new mode 100644
--- a/foo22-link
+++ b/foo22-link
## -1,1 +1,1 ##
-foo22
\ No newline at end of file
+This is no symlink anymore
we get a nice and clean output of
$ diff <(hg files "set:symlink()" -r.) <(hg files "set:symlink()")
0a1
> eeg-link
2d2
< foo22-link
showing the newly-added symlinks (eeg-link) and the removed symlink (foo22-link).
I can get a list of tracked symlinks that are symlinks in the working copy with hg files "set:symlink()", but that doesn't capture the tracked symlinks that aren't symlinks in the working copy.
In case it’s not clear from the other answers, the basic answer to the question is (ignoring any complications induced by bugs outside of Mercurial’s control) to add the -r option to hg files, e,g,
hg -r tip files 'set:symlink()'
I need a mercurail template/keyword "hostname" to get the name (or IP) of the computer where the repo is located. as far as i read the wiki, namely "Chapter 11. Customizing the output of Mercurial", hg help templates, and the web, I think it should be similar to the date keyword, dynamicly expanded. How can i define my own template/keyword?
Thank you verry much
The following extension should do the trick:
from mercurial import templatekw
testedwith = "3.5"
_ipname = None
def showipname(repo, ctx, templ, **args):
""":ipname: String. The hostname of the machine that the repository
resides on."""
import socket
global _ipname
if not _ipname:
_ipname = socket.gethostname()
return _ipname
def uisetup(ui):
templatekw.keywords["ipname"] = showipname
Then use (say):
hg log -r . -T '{node|short} at {ipname}\n'
Note that the value of socket.gethostname() may depend on your internet connectivity. If you need the value in /etc/hostname or something else that identifies your machine, use that method instead.
To use an extension, put it in a file, say ipnametempl.py somewhere, then add the following lines to your .hgrc:
[extensions]
ipnametempl=/path/to/ipnametempl.py
This can be either your user/global hgrc or the .hg/hgrc in your repository (the latter if you only want to enable it for a specific repository). See hg help hgrc to find out where the user/global hgrc files are on your system.
Either the repository is local to your machine (then you can get the absolute path via hg root) and query the name via the normal system tools. You can embed those also in your templates:
$ hg log -r. --template="{branch}-{rev} from $(hostname) running debian $(cat /etc/debian_version)"
trunk-22248 from MYHOSTNAME running debian 8.2
Or you know already the URL (remote path) in order to operate with it as you need to specify it as argument to hg pull/clone/outgoing/incoming
If the remote URL is not explicitly specified on the command line it is specified in your .hgrc in the [path] section. When there is a remote repository at all, then usually a default = URL is defined there.
If you need the URL printed, then install hooks for clone, pull and push (and maybe outgoing and incoming) which prints the $URL as available in those hooks - or maybe just the changegroup hook. Check http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:changegroup and hg help config.
I'm (ab)using Mercurial to manage thousands of files that change often, but I'd like to be able to view the log (hg log) without having my term filled with all of the filenames that changed on each commit. hg log -q is a little too quiet, since I need to see the descriptions. Is there a flag I'm missing for hg log?
It sounds as if you might have the verbose flag turned on. You can check by running hg showconfig and looking for a line like ui.verbose=true.
There are a few ways you can fix it:
remove that line from the offending configuration file (Mercurial can use several, and they vary by OS: use hg help config to list the possibilities).
override the flag in your repository's .hg\hgrc or your private Mercurial configuration (Mercurial.ini or ~/.hgrc): add the following lines to it:
[ui]
verbose=false
clear the verbose flag on the commandline: hg log --config ui.verbose=false.
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.