Differences between revisions 26 and 34 (spanning 8 versions)
Revision 26 as of 2006-08-31 01:53:07
Size: 7978
Editor: FaheemMitha
Comment: Added comment about cloning repos to remove dangling branch.
Revision 34 as of 2006-12-09 20:01:54
Size: 7837
Comment: use only 1 date format
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
}}}
or using the archive command
{{{
cd source
hg archive ../export
Line 19: Line 24:
or using the archive command
{{{
cd source
hg archive -r mytag ../export-tagged
}}}

=== You did an "hg add" on a file but do not want to commit it ===

{{{

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

}}}
Line 39: Line 58:
PARENT=`hg parents $HG_NODE | head -1 | awk -F':' '{print $3}'`
TIP=`hg tip | head -1 | awk -F':' '{print $3}'`
TIP=`hg tip --template '{node|short}'`
PARENT=`hg parents --template '{node|short}' -r $HG_NODE | head -1`
test -n "$PARENT" || exit 0
Line 81: Line 101:
You have the choice between two date output formats:

 * Generic Mercurial output
 * YYYY/mm/dd
Line 97: Line 112:
In "hgpretxncommit.sh" you have to tweak the 'excl' and 'slash' variables
according to your needs. The script doesn't look at files matching $excl.
Whereas files not matching $excl but matching $slash will have the commit
date expanded as YYYY/mm/dd (like the python files in this example).
In "hgpretxncommit.sh" you have to tweak the $excl variable according
to your needs. The script doesn't look at files matching $excl.
Line 105: Line 118:
test $? -eq 0 || exit 1 test $? -eq 0 -a -n "$HG_NODE" || exit 1
Line 107: Line 120:
slash='\.\(\(te\|dt\)x\|s\(ty\|h\)\|c\(fg\|ls\)\|bib\|py\|awk\)$'
Line 109: Line 121:
tipv=`hg tip --verbose`
manifest=`hg manifest | cut -d ' ' -f 3`
slashdate=`echo "$tipv" |
awk '/^date: +/ { printf "%d/%s/%0.2d %s %s", $6, $3, $4, $5, $7 }'`
m=0
for M in Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec; do
    let $((++m))
    slashdate=${slashdate/$M/`printf %0.2d $m`}
done
longdate=`echo "$tipv" | awk -F ': +' '/^date: +/ { print $2 }'`
for f in `echo "$tipv" | awk -F ': +' '/^files: +/ { print $2 }'`; do
    if echo "$f" | grep -v -q "$excl" && echo "$manifest" | grep -x -q "$f"
isodate=`hg tip --template='{date|isodate}'`
for f in `hg status --modified --added --no-status`; do
    if echo "$f" | grep -v "$excl" >/dev/null 2>&1
Line 123: Line 126:
        if echo "$f" | grep -q "$slash"; then
            hgdate="$slashdate"
        else
            hgdate="$longdate"
        fi
sed -i,hg -e "s!\([$]Hg\)[^$]*[$]!\1: ${bn},v $cset $hgdate \$!" "$f" &&
        rm "${f},hg"
        sed -i,hg -e "s!\([$]Hg\)[^$]*[$]!\1: $bn,v $cset $isodate \$!" "$f" \
        && rm "$f,hg"
Line 211: Line 209:
{{{
Line 214: Line 213:
   | R+k (concatentated)    | R+k (concatenated)
Line 217: Line 216:
}}}
Line 220: Line 220:
1) 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.

2) 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.

3) 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.

4) 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.
newrepo will look like

 
R+k (concatentated)
          |
 1. 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.

 2. 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.

 3. 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.

 4. 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.
    newrepo will look like
    {{{
R+k (concatenated)
         |
Line 248: Line 244:

(Would an example here help?)
    }}}
    (Would an example here help?)

=== 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
}}}

Available tips: TableOfContents

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

You did an "hg add" on a file but do not want to commit it

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

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.

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}'`
PARENT=`hg parents --template '{node|short}' -r $HG_NODE | head -1`
test -n "$PARENT" || exit 0
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".

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

Keyword expansion according to file revision

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`; do
    if echo "$f" | grep -v "$excl" >/dev/null 2>&1
    then
        bn="${f##*/}"
        sed -i,hg -e "s!\([$]Hg\)[^$]*[$]!\1: $bn,v $cset $isodate \$!" "$f" \
        && rm "$f,hg"
    fi
done
exit $?

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
}

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"
)

Accessing ssh controlled repositories from a Windows Client

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

  1. Grab putty.exe and plink.exe from [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] website.

  2. Connect to remote ssh host over ssh using PuTTY once and have PuTTY save it's key as a known host.
  3. Add the following to the [ui] section of your ~/Mercurial.ini file

    ssh=/path/to/plink.exe -ssh -i "/path/to/your/private/key"
  4. Profit!!!

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

R+k
 |
  |
   |     R+k (concatenated)
    |     |
     --R--

The procedure is as follows.

  1. 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.
  2. 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.
  3. 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.
  4. 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. newrepo will look like
              R+k (concatenated)
               |
            R--
      (Would an example here help?)

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

TipsAndTricks (last edited 2016-12-05 11:14:36 by ArneBab)