=== Windows: The installer aborts with an error message === "This installation package is not supported by this processor type. Contact your product vendor." This means you are trying to install a 64-bit version installer on a normal 32-bit operating system. You need to download and use the correct msi file for your OS. For normal 32-bit OS, make sure the msi file does not have an x64 in it. === Which revision have I checked out? === Use the [[Cmd:summary]] command (TutorialClone shows an example call). The summary command will also tell you in brief what branch you're on, whether there are any newer changes than the one you're on, and what the state of your working directory is. If you want this for a script and need terser output, take a look at Cmd:identify command flags and at Topic:scripting. === What can I configure in Mercurial === See in MercurialIni. === Configuring the username === If hg says '''No username found, using 'user@hostname instead'''' when you make a commit, then you need to configure your username. Please see QuickStart for help on this. === My repository is corrupted, help! === Please read the page [[RepositoryCorruption|"Dealing With Repository And Dirstate Corruption"]] for recommendations on what to do. === I get an error while cloning a remote repository via ssh === If your remote repository is cloned thusly {{{ hg clone ssh://USER@REMOTE/path/to/repo }}} And, you find that after successful ssh authentication you get the error message '''remote: abort: repository path/to/repo not found!''' , then you need to know the following: * Mercurial's remote [[Repository|repository]] syntax differs from syntax of other well known programs such as rsync, cvs - both of which use a `:` character to delimit {{{USER@REMOTE}}} from the path component ({{{/path/to/repo}}}). * The path to the remote repository is ''relative'' to {{{$HOME}}} of {{{USER}}}. i.e., it is {{{ ~USER/path/to/repo }}}. * Remember to use {{{hg -v clone ssh://USER@REMOTE/path/to/repo}}} and observe the remote command being executed via the ssh channel On the other hand, if the error message is '''remote: bash: line 1: hg: command not found''', the problem is that the environment used by ssh does not have `hg` in its `PATH`. There are a few ways to deal with this problem: * In your client `~/.hgrc` file, set a `remotecmd` value in the `[ui]` section giving the exact path to `hg`. * As a one-off operation, you could write the clone command as follows: {{{ hg --config ui.remotecmd=/path/to/hg clone ssh://USER@REMOTE/path/to/repo }}} * Define a `PATH` in `.bashrc` (or equivalent shell configuration file), noting that this may not always work for some versions of ssh and bash. * On the server, create a `~/.ssh/environment` file that defines an appropriate `PATH`, and add `PermitUserEnvironment yes` to `/etc/sshd_config`. * On the server, place a symlink to the hg binary somewhere on the ssh `PATH`; run `ssh username@server env` to show it. Be careful to avoid paths managed by system package management, since package installations could conflict with it; `/usr/local/bin` is usually a good choice. === I get an "ssl required" error message when trying to push changes === That's because allowing anonymous, unauthenticated HTTP clients to push changes into your repository would be a huge security hole. If you are on a private network and you know that all HTTP clients are trustworthy, you can add {{{ [web] push_ssl = false }}} to `.hg/hgrc` on the ''server''-side repository. (See also HgWebDirStepByStep.) There's a reason for requiring SSL, however. If you do not trust the network you are using do '''not''' change this. === I did an hg pull and my working directory is empty! === There are two parts to Mercurial: the [[Repository|repository]] and the [[WorkingDirectory|working directory]]. {{{hg pull}}} pulls all new changes from a remote repository into the local one but doesn't alter the working directory. This keeps you from upsetting your work in progress, which may not be ready to merge with the new changes you've pulled and also allows you to manage [[Merge|merging]] more easily (see below about best practices). To update your working directory, run {{{hg update}}}. If you're sure you want to Cmd:update your working directory on a Cmd:pull, you can also use {{{hg pull -u}}}. This will refuse to merge or overwrite local changes. === I want to retrieve an old version of my project, what do I do? === You want {{{hg update -C }}}, which will clobber your current version with the requested version. You '''don't''' want {{{hg revert }}}, which reverts changes in your working directory back to that version, but '''keeps''' the current parents for the next checkin. This command exists for undoing changes in current versions, not for working on old versions. === hg status shows changed files but hg diff doesn't! === {{{hg status}}} reports when file '''contents''' or '''flags''' have changed relative to '''either''' parent. {{{hg diff}}} only reports changed '''contents''' relative to the first parent. You can see flag information with the {{{--git}}} option to {{{hg diff}}} and deltas relative to the other parent with {{{-r}}}. === hg export or log -p shows a strange diff for my merge! === The diff shown by {{{hg diff}}}, {{{hg export}}} and {{{hg log}}} is always against the first parent for consistency. Also, the files listed are only the files that have changed relative to ''both'' parents. (Are diffs of merges really always against the first parent? Doesn't {{{hg export}}} have a --switch-parent option? It would also be good if the docs would give the rationale for {{{hg diff}}} and {{{hg log}}} not having that option (assuming they don't--the man page only mentions it for export).) === I did an hg revert and my working directory still has changes in it! === You've probably done an {{{hg merge}}} (see [[Merge]]), which means your [[WorkingDirectory|working directory]] now has two parents according to {{{hg parents}}}. A subsequent {{{hg revert --all -r .}}} will revert all files in the working directory ''back to the first (primary) parent'', but it will still leave you with two parents (see Cmd:revert). To completely undo the uncommitted merge and discard all [[LocalModifications|local modifications]], you will need to issue a `hg update -C -r .` (note the "dot" at the end of the command). See also TutorialMerge. === I want a clean, empty working directory === The easiest thing to do is run {{{hg clone -U}}} which will create a fresh clone without checking out a working copy. If the repository already has a working copy, you can remove it running {{{hg update null}}}. '''Note''': you might want to copy hgrc file from your old [[Repository|repository]]. === I committed a change containing nuclear launch codes, how do I delete it permanently? === If you've just committed it, and you haven't done any other commits or pulls since, you may be able to use Cmd:rollback command to undo the last commit transaction: {{{ $ hg rollback rolling back last transaction }}} If you've made other changes but you haven't yet published it to the world, you can do something like the following: {{{ $ hg clone -r tainted-repo untainted-repo }}} The strip command in the [[MqExtension|mq extension]] may also be useful here for doing operations in place. This will get you a new repo without the tainted change or the ones that follow it. You can import the further changes with {{{hg export}}} and {{{hg import}}} or by using the TransplantExtension. See TrimmingHistory for possible future approaches. If you've already pushed your changes to a public [[Repository|repository]] that people have cloned from, the genie is out of the bottle. Good luck cleaning up your mess. ''“Judge Tries to Unring Bell Hanging Around Neck of Horse Already Out of Barn Being Carried on Ship That Has Sailed.” - William G. Childs'' For more details, see EditingHistory. === I committed a large binary file/files how do I delete them permanently? === If you want to remove file(s) that shouldn't have been added, use the ConvertExtension with {{{--filemap}}} option to "convert" your Mercurial repository to another Mercurial repository. You'll want to make sure that you set {{{convert.hg.saverev=False}}} if you want to keep in common the history prior to your removed file(s). If {{{convert.hg.saverev=True}}}, the conversion embeds the source revision IDs into the new revisions under an {{{extra}}} header, visible if via {{{hg log --debug}}}. See also the previous question for other options. === I tried to check in an empty directory and it failed! === Mercurial doesn't track directories, it only tracks files. Which works for just about everything, except directories with no files in them. As empty directories aren't terribly useful and it makes the system much simpler, we don't intend to fix this any time soon. A couple workarounds: * add a file, like "this-dir-intentionally-left-blank". On *nix, you can do this with `find . -type d -empty -exec touch {}/.keep \;`. There is also the Mono-based tool MarkEmptyDirs which allows to automate this task). * create the directory with your Makefiles or other build processes === I want to get an email when a commit happens! === Use the NotifyExtension === I'd like to put only some few files of a large directory tree (home dir for instance) under Mercurial's control, and it is taking forever to diff or commit === Just do a {{{ printf "syntax: glob\n*\n" > .hgignore }}} or, if you are using 0.7 or below, {{{ printf ".*\n" > .hgignore }}} This will make [[.hgignore|hg ignore]] all files except those explicitly added. === Why is the modification time of files not restored on checkout? === If you use automatic build tools like make or distutils, some built files might not be updated if you checkout an older revision of a file. Additionally a newer [[ChangeSet|changeset]] might have an older commit timestamp due to pulling from someone else or importing [[Patch|patches]] somebody has done some time ago, so checking out a ''newer'' changeset would have to make the files ''older'' in this case. If you need predictable timestamps you can use ''hg archive'', which can do something like a checkout in a separate directory. Because this directory is newly created, there is nothing like switching to a different changeset afterwards, therefore the above mentioned problems don't apply here. === When I do 'hg push' to a remote repository, why does the working directory appear to be empty? === When changes are pushed to a repository, the working directory holding the repository is not changed. However, the changes are stored in the history and are available when performing operations on that repository. Thus, running commands like `hg log` in such a remote repository will show the full history even if a normal directory listing appears to be empty. (Repository publishing using [[PublishingRepositories|hgweb]] also takes advantage of such history being available without needing a set of files in a working directory somewhere.) Obviously, you can run `hg update` to make the files appear in such a repository, but unless you actually want to work within such a directory, it is arguably tidier to leave the directory in its "empty" state. This can be done by issuing an `hg update null` command in the directory holding the repository. === Any way to 'hg push' and have an automatic 'hg update' on the remote server? === {{{ [hooks] changegroup = hg update }}} This goes in {{{.hg/hgrc}}} on the remote [[Repository|repository]]. === How can I store my HTTP login once and for all ? === You can specify the usename and password in the URL like: {{{ http://user:password@mydomain.org }}} Then add a new entry in the ''paths'' section of your hgrc file. With Mercurial 1.3 you can also add an ''auth'' section to your hgrc file: {{{ [auth] example.prefix = https://hg.example.net/ example.username = foo example.password = bar }}} Please see [[http://www.selenic.com/mercurial/hgrc.5.html#auth|the hgrc manpage]] for more information. === How can I do a "hg log" of a remote repository? === You can't. Mercurial accepts only local [[Repository|repositories]] for the -R option (see {{{hg help -v log}}}). {{{ > hg log -R https://www.mercurial-scm.org/repo/hello abort: repository 'https://www.mercurial-scm.org/repo/hello' is not local }}} The correct way to do this is cloning the remote repository to your computer and then doing a {{{hg log}}} locally. This is a very deliberate explicit design decision made by project leader Matt Mackall (mpm). See also Bts:issue1025 for the reasoning behind that. === How can I find out if there are new changesets in a remote repository? === To get the [[ChangeSetID|changeset id]] of the [[Tip|tipmost]] [[ChangeSet|changeset]] of a remote [[Repository|repository]] you can do: {{{ > hg id -i -r tip https://www.mercurial-scm.org/repo/hello 82e55d328c8c }}} When it changes, you have new changesets in the remote repository. === What can I do with a head I don't want anymore? === See PruningDeadBranches === The clone command is returning the wrong version in my workspace! === Clone checks out the tip of the default (aka unnamed) branch (see NamedBranches). Ergo, you probably want to keep your main branch unnamed. === Any way to track ownership and permissions? === If you're using Mercurial for config file management, you might want to track file properties (ownership and permissions) too. Mercurial only tracks the executable bit of each file. Here is an example of how to save the properties along with the files (works on Linux if you've the ''acl'' package installed): {{{ # cd /etc && getfacl -R . >/tmp/acl.$$ && mv /tmp/acl.$$ .acl # hg commit }}} This is far from perfect, but you get the idea. For a more sophisticated solution, check out ''etckeeper''. === I get a "no space left" or "disk quota exceeded" on push === I get a "no space left" or "disk quota exceeded" on push, but there is plenty of space or/and I have no quota limit on the device where the remote hg repository is. The problem comes probably from the fact that mercurial uses {{{/tmp}}} (or one of the directory define by environment variables {{{$TMPDIR, $TEMP}}} or {{{$TMP}}}) to uncompress the bundle received on the wire. The decompression may then reach device limits. You can of course set {{{$TMPDIR}}} to another location on remote in the default shell configuration file, but it will be potentially used by other processes than mercurial. Another solution is to set a hook in a global [[http://www.selenic.com/mercurial/hgrc.5.html|.hgrc]] on remote. See the description of how to set a [[Hook#tmpdirhook|hook for changing tmp directory]] on remote when pushing. === Why do I get "abort: could not import module mpatch!" when invoking hg? === If your current directory is that of the Mercurial source distribution, it is possible that `hg` is looking in the local `mercurial` package directory and fails to find the `mpatch.so` extension module. The solution (for most situations) is to move out of the source distribution directory and to try again. This is a common Python pitfall: Python will often be confused by packages or modules in the current directory and will import packages/modules from these local locations instead of looking in the appropriate places. If you are trying to use `hg` on a checkout of the Mercurial software itself, you might want to check any `PYTHONPATH` environment variable that you may have set and remove "empty" paths. For example, at a shell (`$`) prompt: {{{ $ echo $PYTHONPATH /home/me/lib:/home/me/morelib: }}} Here, the trailing comma (`:`) indicates that there is an empty final path in the list. This empty path is likely to become mapped to the current directory, and Python will then prefer to look at the current directory instead of its own package directories (containing your installed version of Mercurial). If you reset `PYTHONPATH` trimming off any such empty paths, the problem should go away: {{{ $ export PYTHONPATH=/home/me/lib:/home/me/morelib }}} === Why do I get a traceback and ImportError when invoking hg? === See the response to the previous question for a possible explanation and some solutions. === Why do I get "abort: requirement 'fncache' not supported!" when invoking hg? === In version 1.1 of a new repository format was introduced to work around file name limitations on Windows. Repositories created with Mercurial 1.1 or later will automatically have enabled the [[fncacheRepoFormat|fncache repository format]]. You need Mercurial 1.1 or later to read these repositories. Repositories created with pre 1.1 Mercurial or with fncache disabled can still be read. See the page about the [[fncacheRepoFormat|fncache repository format]] for more information. === Why won't Mercurial let me merge when I have uncommitted changes? === If `hg merge` fails with the message `abort: outstanding uncommitted changes`, it means that the usual process of merging two branches cannot proceed. Consider the normal merge case, when the working directory is clean -- that is, there are no uncommitted changes and `hg diff` produces no output. Mercurial combines the revision being merged (the "other branch") with the working directory's revision (the "local branch"). It leaves the result of this merge in your working directory for you to test. When you approve the merge result, you commit it. The key insight: ''all'' of those changes are the result of the merge, i.e. they come from the local head, or the other head, or the combination (merge) of them. Now consider what happens if the working directory already contains modified files -- that is, `hg diff` produces output. In this case, Mercurial has ''three'' states to worry about: your uncommitted changes, the local head, and the other head. That would be incoherent, since Mercurial only allows merging two heads (changesets) at a time. You might think Mercurial should save your uncommitted changes somewhere so you can do the merge and then restore your original changes, but that introduces additional complexity. (What if your merge affects some of the same code as your uncommitted changes? That means another merge will be required in the working directory after you commit the merge you were trying to do in the first place!) So Mercurial does not try; it requires you to have a clean working directory when you try to merge two heads. In short, Mercurial is trying to keep one operation separate from another (local changes versus the merge) and avoid putting the working directory into some kind of special state (suspending local changes until they can be combined with the current revision). There are four ways around this limitation: 1. discard your uncommitted changes (only appropriate if they are temporary throwaway changes, and you don't need them anymore) 1. commit your changes (only appropriate if they are done, working, and ready to commit) 1. create a new working directory 1. set aside your changes The first two should be self-explanatory. Creating a new working directory is a bit more overhead, but is simple and usually fast (unless your repository is very large). For example: {{{ orig=`pwd` hg clone -u . . ../temp-merge cd ../temp-merge hg merge [...test the merge...] hg commit -m"merge with ..." hg push # to your previous repository cd $pwd hg update # to the new merge changeset }}} Setting aside half-finished changes is an interesting problem with a variety of solutions, including but not limited to: * diff + patch * Use the [[ShelveExtension|Shelve]] extension * [[MqExtension|MQ (Mercurial Queues)]] (''not for beginners!'') === How do I overwrite branch x with branch y? === {{{ hg update x hg commit --close-branch -m 'closing branch x, will be overwriten with branch y' hg update y hg branch -f x hg ci }}} The result is a closed head in branch x, and a new commit which has as parent branch y. Don't try to just overwrite files in branch x with files in branch y because it will screw up future merges. This seems the correct way to do it.