Differences between revisions 65 and 73 (spanning 8 versions)

(see also ["FAQ"])

Basic

1. Search history for keywords

hg log has a keyword search feature that scans commit filenames, users, and descriptions:

$ hg log -k bug -k manifest.py
changeset: 2857:18cf5349a361
user: Alexis S. L. Carvalho <alexis@cecm.usp.br>
date: Sat Aug 12 08:53:23 2006 -0300
summary: Fix some bugs introduced during the manifest refactoring

changeset: 1650:f2ebd5251e88
user: Peter van Dijk <peter@dataloss.nl>
date: Sun Jan 29 00:18:52 2006 +0100
summary: changed template escape filter, added urlescape filter; audited all templates for insertion bugs; added note to manifest.py about newlines in filenames

changeset: 1451:54e4b187f69c
user: Matt Mackall <mpm@selenic.com>
date: Tue Oct 25 22:15:44 2005 -0700
summary: Remove old manifest diff code, it's now buggy

Note: hgweb's search box will also scan for keywords, tags, revisions, or changeset IDs.

2. Undo an "hg add"

hg revert # take out of source control
hg rm -f # remove it

3. Save a push URL so that you don't need to enter it each time

It is possible to store a default push URL that will be used when you type just "hg push". Edit .hg/hgrc and add something like :

[paths]
default-push = ssh://hg@example.com/path

4. Track changes to a repository with RSS

You can track changes to projects and individual files with RSS feeds from hgweb. Here are some examples:

http://selenic.com/hg/rss-log/ http://selenic.com/hg/rss-log/tip/mercurial/hgweb/hgweb_mod.py

5. Create links to snapshots of files and tarballs

If you want to create web links to tagged or tip versions of a repository or a file, you can do so like this:

6. Create a bundle of all changes

The best way to create a compressed version of a repository is with a bundle. It will be significantly smaller than a tarball or a zip file. To include all revisions, simply specify the null base:

$ hg bundle --base null project.hg

7. Looking inside bundle files

Bundle files may contain either all or some of the changesets in a repository. To view a partial bundle, you must have a repository containing the bundle's base changesets. Then you can overlay the bundle on top of the repo like so:

$ cd repo
$ hg in bundle.hg # view the changesets added by the bundle
$ hg -R bundle.hg log # view the log of repo+bundle
$ hg -R bundle.hg diff -R tip # compare the working dir to the bundle's tip
$ hg -R bundle.hg cat -r tip foo.txt # extract a particular file

8. Ignore files from Emacs/XEmacs

Add the following to .hgignore:

syntax: glob
*~

syntax: regexp
(.*/)?\#[^/]*\#$

9. Make a clean copy of a source tree, like CVS export

hg clone source export
rm -rf export/.hg

or using the archive command

cd source
hg archive ../export

The same thing, but for a tagged release:

hg clone --noupdate source export-tagged
cd export-tagged
hg update mytag
rm -rf .hg

or using the archive command

cd source
hg archive -r mytag ../export-tagged

10. One liner to remove unknown files with a pattern

To make these work, replace the ls -l with the command you wish to execute (ie. rm). You can also tweak the parameters passed to hg status to filter by something other than unknown files (see hg help status).

hg status -nu0 | grep -z pattern | xargs -0r ls -l

The above command requires a current version of GNU grep. If you don't have one, you can use the following:

hg status -nu | grep pattern | tr '\n' '\0' | xargs -0r ls -l

Intermediate

1. using vimdiff to view single diffs

    hg cat <filename> | vim - -c  ":vert diffsplit <filename>" -c "map q :qa!<CR>";

Using bash to save as a command:

hgdiff() {
    hg cat $1 | vim - -c  ":vert diffsplit $1" -c "map q :qa!<CR>";
}

Then just use hgdiff <filename> to invoke, and q from within vim to quit.

2. using rsync to 'push' and 'pull'

This script will perform a pull from an rsync path:

cd `hg root`
rm -rf .hg/rsync
hg clone -U . .hg/rsync # make an approximate copy to rsync over
rsync -ae ssh $1/.hg .hg/rsync # rsync over our copy
hg pull .hg/rsync # pull from our copy
rm -rf .hg/rsync

Use like this:

$ rsyncpull user@server:repo/foo
pulling from .hg/rsync
searching for changes
adding changesets
adding manifests
adding file changes
added 57 changesets with 153 changes to 65 files
(run 'hg update' to get a working copy)

Similarly, we can push with a script like this:

cd `hg root`
rm -rf .hg/rsync
hg clone -U . .hg/rsync
rsync -ae ssh $1/.hg .hg/rsync
hg push .hg/rsync
rsync -ae ssh .hg/rsync $1/.hg
rm -rf .hg/rsync

This push script ignores locking issues - don't use it for pushing to a repository with multiple writers!

3. pruning dead branches

If you've got a dead branch you'd like to eliminate from the list of heads, you can do a 'no-op merge' to remove it:

$ hg update -C tip # jump to one head
$ hg merge otherhead # merge in the other head
$ hg revert -a -r tip # undo all the changes from the merge
$ hg commit -m "eliminate other head" # create new tip identical to the old

4. generate a diff between two repositories

Usually, you can use the -p option to either incoming or outgoing. Example:

cd /path/to/repo1
hg incoming -p /path/to/repo2

Sometimes you may want a single diff. There are a number of ways to do this. We'll describe two:

a) The clone method

The basic idea is to use a cheap temporary clone to do the work. If the diff is agreeable, you can then pull from your temporary clone.

MYTIP=`hg tip --template "rev"`
hg clone -U . tmp # make a temporary clone with no working directory
hg -R tmp pull http://remoterepo # pull the remote changes into the temporary repo
hg -R tmp diff -r $MYTIP -r tip #
rm -rf tmp

b) The bundle method

MYTIP=`hg tip --template "{rev}"`
hg in -q --bundle tmp.hg http://remoterepo && hg -R tmp.hg diff -r $MYTIP -r tip

This grabs a bundle of incoming changes then overlays the bundle on your current repo to generate the diff. If the diff is agreeable, you can unbundle the repo to make the changes permanent.

5. Adding a commit message template

Mercurial calls a user-defined program to edit commit messages. If that program returns false, the commit is aborted.

Here's an example patch for hgeditor that adds a user-defined template to the commit message:

diff -r 33988aaa1652 hgeditor
--- a/hgeditor Sun Dec 17 22:16:57 2006 -0600
+++ b/hgeditor Tue Dec 19 08:08:57 2006 -0600
@@ -39,6 +39,7 @@ HGTMP="${TMPDIR-/tmp}/hgeditor.$RANDOM.$
     done
 )

-cat "$1" > "$HGTMP/msg"
+cat `hg root`/.commit-template > "$HGTMP/msg"
+cat "$1" >> "$HGTMP/msg"

 MD5=$(which md5sum 2>/dev/null) || \

Validating that the commit message is correct can either be done by hgeditor or enforced by a precommit hook.

6. hg diff does not support -foo option like gnu diff does

I use the following bash function to put the diff options I like most

hgdi ()
{
  for i in `hg status -marn "$@"`
  do
    diff -ubwd <(hg cat "$i") "$i"
  done
}

7. See diffs when editing commit message with VIM

Make a private copy of the 'hgeditor' script provided with mercurial and replace the call to the editor with following command:

vim "+e $HGTMP/diff" '+set buftype=help filetype=diff' "+vsplit $HGTMP/msg" || exit $?

This will start up VIM in vertical split mode with commit message in the left pane and diff in the right pane. The buftype=help setting for diff window tells vim to exit when all other windows are closed, so when you write and quit the log with :x (:wq - they are equivalent), vim exits. If you have syntax highlight set up, the diff will be properly highlighted.

This setting is suitable for wide terminals. If you have a narrow terminal, you may want to replace the +vsplit above with +split or add nowrap to the +set.

8. See diffstat of pulled changes

Place the following script (named "pull-diffstat" here) somewhere in your $PATH:

test -n "$HG_NODE" || exit 0
TIP=`hg tip --template '{node|short}'`
REV=`hg log -r $HG_NODE --template '{rev}'`
test -n "$REV" -a $REV -ne 0 || exit 0
PREV=`expr $REV - 1`
PARENT=`hg log -r $PREV --template '{node|short}'`
echo "diffstat for $PARENT to $TIP"
hg diff -r $PARENT -r tip | diffstat

Add a changegroup entry to the [hooks] section of hgrc:

[hooks]
changegroup = pull-diffstat

Now you will see a diffstat of the new changes to your repo every time you do "hg pull".

9. Accessing ssh controlled repositories from a Windows Client

NOTE: The following works for cases when the private keys are not Password phrase encrypted.

Grab putty.exe and plink.exe from [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] website.
Connect to remote ssh host over ssh using PuTTY once and have PuTTY save it's key as a known host.
Add the following to the [ui] section of your ~/Mercurial.ini file
```
ssh=/path/to/plink.exe -ssh -i "/path/to/your/private/key"
```
Profit!!!

This didn't work for me with the latest windows version, maybe because I'm using key authentication with a passphrase. I got cygwin ssh to work though. Follow the instructions for this on [wiki:WindowsInstall WindowsInstall ssh help]. -- krupan DateTime(2006-12-15T22:13:42Z)

I got this to work with my passphrase-locked ssh keys by following the directions below, but the Mercurial.ini syntax above seemed to be very sensitive. It didn't work when I put quotes around /path/to/plink. That took a while to figure out :-( -- krupan

Also observed the effect above: no attempts to quote plink path worked - very ugly errors, like remote: Incorrect file name, directory name, or volume label. abort: no suitable response from remote hg! and unquoted path like C:\Program Files\Putty\plink.exe resulted in attempts to run C:\Program. I ended up creating C:\Bin and copying plink.exe there. Interesting that path to key could be quoted. -- Marcin.Kasperski

To get your passphrase-locked SSH keys to work properly under PuTTY, you'll need to go through the following steps.

Download putty.exe, puttygen.exe, pageant.exe, and plink.exe from the [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY website]. You may want pscp.exe as well if you plan to do SCP, but it's not necessary for running Mercurial.
Copy your SSH private key onto your Windows machine.
PuTTY uses its own private format for SSH private keys, so you'll need to convert your private key. Run puttygen.exe and choose Import key from the Conversions menu.
Import your private key; enter its passphrase when prompted.
Change the key comment to something meaningful.
Click the Save private key button and save the .PPK file somewhere.
Run pageant.exe. The pageant icon (a computer wearing a hat) will show up in the status tray.
Right-click the pageant icon and choose Add Key.
Choose the .PPK file you saved earlier and type in its passphrase.
Follow steps 2 & 3 above: connect to the remote host, save its key, and edit your Mercurial.ini file.
Enjoy your newly-secure SSH authentication on Windows!
- -- RobinMunn

Note that pageant.exe caches your unlocked key in memory, which could conceivably make its way into your swap file. Be aware of the security implications of that fact. (For example, if your computer is ever stolen, it would be wise to consider that SSH key compromised and change it as soon as possible).

Advanced

1. Keyword expansion according to file revision

(also see KeywordPlan and KeywordExpansionExtension)

This is an example on how you can achieve filewise keyword expansion (similar to CVS) with an [encode] filter and the pretxncommit-hook. Comes in handy when you want to keep track of different file revisions in the same repository.

For demonstration we use just one keyword: "Hg".

$Hg$

It will be expanded by the script "hgpretxncommit.sh" (see below) to:

$Hg: <basename of file>,v <short hash> <date> $

You need an [encode] filter that "reverts" the expansion in your hgrc.

Simple example hgrc for a repository containing python files:

[encode]
*.py = sed 's/[$]Hg[^$]*[$]/\$Hg\$/'
[hooks]
pretxncommit = hgpretxncommit.sh

In "hgpretxncommit.sh" you have to tweak the $excl variable according to your needs. The script doesn't look at files matching $excl.

set -e
test $? -eq 0 -a -n "$HG_NODE" || exit 1
excl='^\.hg\|\.\(p\(df\|ng\)\|jpg\)$'
cset="${HG_NODE:0:12}"
isodate=`hg tip --template='{date|isodate}'`
for f in `hg status --modified --added --no-status \
    | grep --invert-match "$excl" 2>/dev/null`; do
    bn="${f##*/}"
    sed -i~ -e "s!\([$]Hg\)[^$]*[$]!\1: $bn,v $cset $isodate \$!" "$f"
done
exit $?

2. upgrading a repository to revlogng in place

Here's a quick and dirty script to upgrade a mercurial repository in place. Note: the current undo information will be lost.

function upgradehg () (
  if test -n "$1"
  then
    local repo="$1"
    local tmprepo="$1".tmp
  else
    local repo="."
    local tmprepo="../hgupgrade.tmp"
  fi

  set -e
  hg clone --pull -U "$repo" "$tmprepo"
  cp "$repo"/.hg/{hgrc,dirstate} "$tmprepo"/.hg
  mv "$repo"/.hg "$repo"/.hg.orig
  mv "$tmprepo"/.hg "$repo"/.hg
  rmdir "$tmprepo"
  echo "Upgrade complete. A backup of your original repository is now in $repo/\.hg.orig"
)

3. Concatenating multiple changeset into one changeset.

Suppose you have a repository with a number of changesets which you want to combine into a single changeset.

This can be done as follows using only the basic operations of mercurial, namely clone, push, pull.

For simplicity, let us assume that the repository in question has a single head, and you want to combine the last k revisions into a single revision.

For concreteness, let us call the base revision R, and the ending revision R+k.

Let us furthermore assume the repository has no local changes.

The strategy is to take advantage of mercurial's support for repositories with more than one head. What we do is create a branch whose root revision is R and which consists of just one changeset (actually it can be multiple changesets, the principle is the same, but for simplicity let us assume one).

Diagramatically, this looks like:

The procedure is as follows.

hg update R
- This updates the working directory to revision R. Specifically, this means that the contents of the working directory are changed to that of revision R, and that R becomes the parent of the working directory.
hg revert -r tip
- This reverts the working directory revert to its contents at tip. Since the parent of the working directory is still R, this means that the combined contents of all changesets between R and R+k show up as the modifications in the working directory.
hg ci -m "Combined changesets between R and R+k"
- At this point, committing these modifications will create a changeset containing all combined changesets between revisions R and R+k.
hg clone -r tip oldrepo newrepo
- This assumes you want to get rid of your individual changesets (which are a dangling branch in oldrepo) and just keep the combined changeset. newrepo will now just have the combined changeset.

4. Recreate hardlinks between two mercurial repositories

When repositories are cloned locally, their data files will be hardlinked so that they only use the space of a single repository. Unfortunately, subsequent pulls into either repository will break hardlinks for any files touched by the new changesets, even if both repositories end up pulling the same changes. Here's a quick and dirty way to recreate those hardlinks and reclaim that wasted space:

import os, sys

class ConfigError(Exception): pass

def usage():
    print """relink <source> <destination>
    Hard-link files from source to destination"""

class Config:
    def __init__(self, args):
        if len(args) != 3:
            raise ConfigError("wrong number of arguments")
        self.src = os.path.abspath(args[1])
        self.dst = os.path.abspath(args[2])
        for d in (self.src, self.dst):
            if not os.path.exists(os.path.join(d, '.hg')):
                raise ConfigError("%s: not a mercurial repository" % d)

try:
    cfg = Config(sys.argv)
except ConfigError, inst:
    print str(inst)
    usage()
    sys.exit(1)

relinked = 0
savedbytes = 0
CHUNKLEN = 4096

def collect(src):
    seplen = len(os.path.sep)
    candidates = []
    for dirpath, dirnames, filenames in os.walk(src):
        relpath = dirpath[len(src) + seplen:]
        for filename in filenames:
            if not (filename.endswith('.i') or filename.endswith('.d')):
                continue
            st = os.stat(os.path.join(dirpath, filename))
            candidates.append((os.path.join(relpath, filename), st))

    return candidates

def prune(candidates, dst):
    targets = []
    for fn, st in candidates:
        tgt = os.path.join(dst, fn)
        try:
            ts = os.stat(tgt)
        except OSError:
            # Destination doesn't have this file?
            continue
        if st.st_ino == ts.st_ino:
            continue
        if st.st_dev != ts.st_dev:
            raise Exception('Source and destination are on different devices')
        if st.st_size != ts.st_size:
            continue
        targets.append((fn, ts.st_size))

    return targets

def relink(src, dst, files):
    CHUNKLEN = 65536
    relinked = 0
    savedbytes = 0

    for f, sz in files:
        source = os.path.join(src, f)
        tgt = os.path.join(dst, f)
        sfp = file(source)
        dfp = file(tgt)
        sin = sfp.read(CHUNKLEN)
        while sin:
            din = dfp.read(CHUNKLEN)
            if sin != din:
                break
            sin = sfp.read(CHUNKLEN)
        if sin:
            continue
        try:
            os.rename(tgt, tgt + '.bak')
            try:
                os.link(source, tgt)
            except OSError:
                os.rename(tgt + '.bak', tgt)
                raise
            print 'Relinked %s' % f
            relinked += 1
            savedbytes += sz
            os.remove(tgt + '.bak')
        except OSError, inst:
            print '%s: %s' % (tgt, str(inst))

    print 'Relinked %d files (%d bytes reclaimed)' % (relinked, savedbytes)

src = os.path.join(cfg.src, '.hg')
dst = os.path.join(cfg.dst, '.hg')
candidates = collect(src)
targets = prune(candidates, dst)
relink(src, dst, targets)

Diff for "TipsAndTricks"