|
Size: 10341
Comment: +clone command is returning the wrong version
|
Size: 10809
Comment: another ssh problem
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| 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 two ways to deal with this problem: * In your `~/.hgrc` file, set a `remotecmd` value in the `[ui]` section giving the exact path to `hg`. * On the server, create a `~/.ssh/environment` file that defines an appropriate `PATH`, and add `PermitUserEnvironment yes` to `/etc/sshd_config`. |
|
| Line 18: | Line 22: |
| If you're on a network you trust you can add | If you're on a network you trust you can add |
| Line 39: | Line 43: |
| want to [:Update:update] your working directory on a pull, you can also use | want to [:Update:update] your working directory on a pull, you can also use |
| Line 50: | Line 54: |
| {{{hg status}}} reports when file '''contents''' or '''flags''' have changed relative to '''either''' [:Parent: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 status}}} reports when file '''contents''' or '''flags''' have changed relative to '''either''' [:Parent: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}}}. |
| Line 66: | Line 70: |
| If you're trying to switch between [:Revision:revisions] in history, you probably want | If you're trying to switch between [:Revision:revisions] in history, you probably want |
| Line 110: | Line 114: |
| See CommitHook for an example. | Use the NotifyExtension |
| Line 146: | Line 150: |
| When this first happened, mercurial told you what to do, but if you've lost | When this first happened, mercurial told you what to do, but if you've lost |
What can I configure in Mercurial
See in MercurialIni.
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 two ways to deal with this problem:
In your ~/.hgrc file, set a remotecmd value in the [ui] section giving the exact path to hg.
On the server, create a ~/.ssh/environment file that defines an appropriate PATH, and add PermitUserEnvironment yes to /etc/sshd_config.
I get an "ssl required" error message when trying to push changes
If you're on a network you trust you can add
[web] push_ssl = false
in your <repository-name>/.hg/hgrc file. (Taken from 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 [: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 [:Update:update] your working directory on a 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 <version>, which will clobber your current version with the requested version.
You don't want hg revert <version>, 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: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:diff] shown by hg diff, hg export and hg log is always against the first [:Parent: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 rational 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 [:Parent:parents] according to hg parents. A subsequent hg revert will revert your working directory back to the primary parent, thus leaving you with the differences between the two parents. hg update -C will revert the left files.
(Surely this can only happen if you specified specific files/directories to the revert command, right? If you specify the --all argument instead then I'd assume (hope!) the working copy state is identical to the state as recored by the primary parent and no non-primary parent changes are left. If this isn't the case then it would be very helpful if a sentence or two could be added to explain why.)
(Also note this section conflicts with the text in the man page which says there is no default selection if there are two parents: "If the working directory has two parents, you must explicitly specify the revision to revert to.")
If you're trying to switch between [:Revision:revisions] in history, you probably want hg update -C.
I want a clean, empty working directory
The easiest thing to do is run hg clone -U which will create a fresh [:Clone:clone] without checking out a working copy.
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 [:Commit:committed] it, and you haven't done any other commits or [:Pull:pulls] since, you may be able to use rollback (see ["Rollback"]) 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 <untainted-revision> 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 [:Clone: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 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"
- 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:commit] timestamp due to [:Pull: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.
My merge program failed, and now I don't know what to do
If your [:MergeProgram:merge program] fails you'll find yourself in a state where both hg up and hg merge produce the same, unhelpful output.
abort: outstanding uncommitted merges
When this first happened, mercurial told you what to do, but if you've lost those instructions, the only way to get them back is to run "hg rollback" and repeat the action.
Why does hg merge not invoke merge again? Why the unhelpful output?
Any way to 'hg push' and have an automatic 'hg update' on the remote server?
[hooks] changegroup = hg update >&2
This goes in .hg/hgrc on the remote [:Repository:repository]. Output has to be redirected to stderr (or /dev/null), because stdout is used for the data stream.
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.
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 http://www.selenic.com/repo/hello abort: repository 'http://www.selenic.com/repo/hello' is not local
The correct way to do this is [:Clone: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 http://www.selenic.com/mercurial/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 http://www.selenic.com/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.