add

指定ファイルの追加登録予約:

hg add [OPTION]... [FILE]...

構成管理へのファイルの追加登録を予約します。

指定されたファイルは、 次回のコミットから構成管理対象となります。 追加登録のコミット前取り消しは hg help forget を参照してください。

ファイル名指定が無い場合、 作業領域中の全ファイルが対象となります (.hgignore による無視指定対象は除く)。

全てのファイルの登録が成功した場合のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

addremove

新規ファイルの追加登録、 および不在ファイルの登録除外:

hg addremove [OPTION]... [FILE]...

作業領域中の新規ファイルの追加登録、 および全不在ファイルの登録除外を 行ないます。

.hgignore 中の記述パターンに合致するファイルは、 明示的な指定がない限り、 無視されます。 hg add と同様に、 実行効果が発揮されるのは、 次回の hg commit 時点です。

ファイルの改名を検知するには -s/--similarity を使用します。 これは、 0 (改名比較無し) から 100 (完全一致で判定) の範囲で、 類似度を指定 するオプションです (パーセンテージ指定)。 0 より大きい指定値の場合、 全ての追加／除外ファイル対象として、 改名の有無が判定されます。 改名判定には、 相応の時間を要する場合があります。 判定結果の確認は、 本コマンドの実行後に hg status -C 出力を参照してください。 -s/--similarity 未指定の場合、 100 が指定されたものとみなされ、 内容が完全に一致するファイルのみが、 改名とみなされます。

全てのファイルの登録が成功した場合のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

annotate

ファイル行毎のリビジョン情報表示:

hg annotate [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] FILE...

ファイルの各行毎に、 その内容が由来するリビジョンIDを表示します。

本コマンドは、 変更の実施者または実施時期を特定するのに有用です。

--file, --user, --date のいずれかが指定された場合、 明示的な --number 指定がない限り、 由来リビジョン番号は表示されません。

-a/--text 指定が無い場合、 バイナリと思しきファイルは処理対象から 除外されます。 -a 指定が有る場合、 結果の有用性の有無に関わらず 全てのファイルが処理対象となります。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: blame

archive

特定リビジョン時点のアーカイブのリポジトリ外への生成:

hg archive [OPTION]... DEST

特に指定が無い場合、 作業領域の親リビジョンが使用されます。 他のリビジョンを指定する場合は -r/--rev を使用します。

アーカイブ種別は、 出力先ファイルの拡張子から自動的に判定されますが、 -t/--type で強制することも可能です。

有効種別一覧:

アーカイブ生成先となるファイル名またはディレクトリ名の指定には 置換指定を使用することができます。 置換指定に関する詳細は hg help export を参照してください。

アーカイブ生成の際には、 展開時の格納先ディレクトリ名が記録されます。 -p/--prefix によりディレクトリ名を指定できます(置換指定可能)。 特に指定が無い場合、 アーカイブファイルへのパスの末尾要素から、 拡張子を除いたものが記録されます。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

backout

以前のリビジョンにおける変更の打ち消し:

hg backout [OPTION]... [-r] REV

対象リビジョン内容の打ち消しに相当する変更を、 作業領域で作成します。 衝突なしで打ち消しができた場合は、 変更内容を自動的にコミットします。

作業領域の親リビジョンを打ち消す場合、 打ち消しに相当する内容は、 自動的にコミットされます (--no-commit 指定時を除く)。

-d/--date での日時表記は hg help dates を参照してください。

ファイルの内容を、 別のリビジョン時点のもので上書きする方法は、 hg help revert を参照してください。

成功時のコマンド終了値は 0、 打ち消しが必要なリビジョンが無い場合や、 未解消の衝突が発生した場合は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

bisect

リビジョンの二分探索:

hg bisect [-gbsr] [-U] [-c CMD] [REV]

問題発生契機となるリビジョンを探索します。 使用開始の際には、 問題が発生する既知のリビジョンのうち、 最古のものを bad とマークし、 問題が発生しない既知のリビジョンのうち、 最新のものを good とマーク します。 本コマンドは、 検証対象リビジョンで作業領域を更新します(-U/ --noupdate 指定時除く)。 当該リビジョンを検証したなら、 bad あるいは good でマークしてください。 本コマンドは、 次の検証候補リビジョンで 作業領域を更新するか、 問題契機リビジョンを特定できた旨を出力します。

簡便な手順としては、 作業領域を更新せず、 リビジョン指定を使用して、 リビジョンを good または bad にマークすることもできます。

コマンドが指定された場合、 自動的なリビジョン検証に使用されます。 コマンド実行時には、 環境変数 HG_NODE に検証対象リビジョンの ID が格納されます。コマンドの終了コードは、 リビジョンに対する bad または good のマーク付けに使用されます。終了コード 0 は good、 125 はリビジョンのスキップ、 127 (コマンド不在) は探索の中止、 その他の非 0 終了コードは bad とみなされます。

成功時のコマンド終了値は 0 です。

オプション:

bookmarks

ブックマークの、新規作成、又は既存の一覧表示:

hg bookmarks [OPTIONS]... [NAME]...

リビジョンへのラベルであるブックマークは、 作業履歴の追跡を助けます。 ブックマークへの操作は履歴記録されず、 移動・削除・改名も可能です。 ブックマークの削除・移動による、 対象リビジョンへの影響はありません。

ブックマークの作成や更新は、 ブックマークを 'アクティブ' 化します。 アクティブなブックマークは '*' 付きで表示されます。 コミットの際に、 アクティブなブックマークの参照先は、 新規リビジョンへと移動します。 アクティブブックマークは、 リビジョン指定無し hg update で移動が、 リビジョン指定付き hg update で非アクティブ化が発生します。

ブックマークは、 リポジトリ間での取り込みや反映が可能です (hg help push および hg help pull 参照)。 連携先リポジトリで、 同名ブックマークの参照先が分岐 (divergent) する場合、 'ブックマーク名@連携先' 形式の '分岐ブックマーク' が新規作成されます。 履歴の分岐は hg merge で解消してください。

ブックマーク '@' が存在する場合、 hg clone での作業領域更新の、 デフォルト対象リビジョンとして使用されます。

オプション:

branch

ブランチ名の設定、 または現ブランチ名の表示:

hg branch [-fC] [NAME]

引数無しの場合、 現ブランチ名を表示します。 引数が１つ指定された場合、 作業領域のブランチ名を設定します(次回コミット時まで、 ブランチは生成 されません)。 作業時に基本とするブランチには、 'default' ブランチを 使用することをお勧めします。

-f/--force 指定が無い場合、 既存ブランチと同じ名前は設定できません。

-C/--clean を指定することで、 以前のブランチ名設定を無効にして、 作業 領域の親リビジョンのブランチ名に戻します。

作業領域を既存ブランチの内容で更新するには hg update を使用します。 現ブランチヘッドの閉鎖には hg commit --close-branch を使用します。 全ブランチヘッドの閉鎖をもって、 当該ブランチの閉鎖とみなします。

成功時のコマンド終了値は 0 です。

オプション:

branches

リポジトリ中の名前付きブランチの一覧:

hg branches [-c]

リポジトリ中の名前付きブランチを、 非アクティブ (inactive) か否かと共に一覧表示します。 -c/--closed 指定時には、 閉鎖済みのブランチ (hg commit --close-branch 参照) も表示されます。

作業領域の内容を既存ブランチのもので更新する場合は hg update を 使用してください。

コマンドの終了値は 0 です。

オプション:

bundle

バンドルファイルの生成:

hg bundle [-f] [-t TYPE] [-a] [-r REV]... [--base REV]... FILE [DEST]

連携対象リポジトリに存在しないリビジョンの情報を、 バンドルファイルに書き出します。

-a/--all (又は --base null) 指定がある場合、 バンドルファイルには、 リポジトリの全ての履歴が書き出されます。 明示的な --base 指定の場合、 指定リビジョン以降の履歴が書き出されます。 それ以外の場合は、 指定の連携先 (又は paths での default-push/default 指定先) から、 書き出し対象リビジョンを判断します。

出力形式は -t/--type で指定可能です。 圧縮形式名、 バンドル形式名、 あるいは - で連結した併記形式 (comp-bundle) で指定できます。 利用可能な圧縮形式は none (無圧縮), bzip2, gzip です。 (デフォルト値: bzip2) 利用可能なバンドル形式は v1 と v2 です。 (デフォルト値: 自動選択)

バンドルファイルは hg unbundle または hg pull によって、 他リポジトリに取り込めるので、 変更内容を任意の方法で伝播できます。 バンドルファイルによる伝播は、 hg push/hg pull での直接転送や、 リポジトリ全体の公開が、 できない／望ましく無い場合に有用です。

バンドルファイルによる取り込みでは、 権限設定、 複製／改名、 変更履歴等を含む全ての更新内容が取り込まれます。

成功時のコマンドの終了値は 0、 変更が検出できない場合は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

cat

指定されたリビジョン時点のファイル内容の出力:

hg cat [OPTION]... FILE...

指定されたリビジョン時点でのファイル内容を出力します。 リビジョンが 指定されない場合は、 作業領域の親リビジョン時点の内容を表示します。

出力先指定(置換指定可能)がある場合、 出力はファイルに保存されます。 置換指定として以下のものが使用可能です:

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

clone

既存リポジトリの複製:

hg clone [OPTION]... SOURCE [DEST]

既存リポジトリを、 新規ディレクトリに複製します。

複製先ディレクトリ指定が無い場合、 複製元パス名の末尾要素を使用します。

後々の hg pull 実施に備えて、 複製先リポジトリの .hg/hgrc ファイルには、 複製元リポジトリ位置が default 名義で記録されます。

複製先に指定可能なのは、 ローカルファイルシステム上のパスと、 ssh:// 形式 URL のみです。 ssh:// 形式 URL を指定した場合、 作業領域の更新や、 .hg/hgrc の生成は行われません。

複製元リポジトリにブックマーク '@' が設定されている場合、 特に指定がなければ、 複製先の作業領域は、 そのリビジョンで更新されます。

特定のリビジョンで、 作業領域を更新する場合は -u/--update を、 作業領域にデータを持ちたくない場合は -U/--noupdate を指定します。

-r/--rev でのリビジョン指定や、 -b/--branch でのブランチ指定により、 一部のリビジョンのみを取り込むことができます。 複製先のリポジトリは、 指定リビジョンと、 その祖先のみを保持します。 これらのオプション指定 (あるいは hg clone src#rev dest 形式での複製) がある場合、 同一ファイルシステム上のリポジトリの複製でも、 --pull 指定時と、 同様に振舞います。

$ cp -al REPO REPOCLONE

URL 記述の詳細は hg help urls を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

commit

指定ファイルまたは全ての変更内容のリポジトリへの記録:

hg commit [OPTION]... [FILE]...

指定されたファイルの変更内容を、 管理領域に記録 (コミット) します。 中央集権的な構成管理ツールと異なり、 この操作で変更が記録されるのは、 手元の管理領域に対してのみです。 能動的な変更伝播に関しては、 hg help push を参照してください。

ファイル指定が省略された場合、 hg status により検出される全ての 変更内容がコミットされます。

hg merge 結果をコミットする場合、 ファイル名または -I/-X の、 いずれも指定しないでください。

コミットログが指定されない場合、 メッセージ入力用のプログラムが、 設定に従って起動されます。 コミット処理が失敗した場合でも、 入力したメッセージは .hg/last-message.txt に保存されます。

--close-branch 指定により、 現ブランチヘッドが閉鎖されます。 当該ブランチにおける、 全ブランチヘッドの閉鎖をもって、 そのブランチの閉鎖とみなし、 以後は一覧に列挙されません。

--amend を指定した場合、 作業領域の親リビジョンの持つ変更内容に、 hg status が表示する変更内容 (変更がある場合) を加えたもので、 作業領域の親リビジョンを改変します。 改変前のリビジョンの内容は、 バンドル形式で .hg/strip-backup にバックアップされます。 (復旧方法は hg help bundle および hg help unbundle を参照). (※ 訳注: --amend 指定時は、 対象ファイルを指定しても、 追加記録分の選択にのみ使用され、 記録済みファイルの取捨選択には、 影響しません。 MQ エクステンションの hg qrefresh における --short 指定と同等な挙動となります。)

コミットログ、 ユーザ名、 記録日付は、 明示的な指定が無い限り、 改変対象のリビジョンのものが再利用されます。 コマンド行において、 コミットログが指定されない場合、 改変前のメッセージを使って、 エディタが起動されます。

public フェーズ (hg help phases 参照) のリビジョンや、 既に子リビジョンを持つリビジョンは、 改変できません

-d/--date での日時表記は hg help dates を参照してください。

成功時のコマンドの終了値は 0、 変更が検出できない場合は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: ci

config

全設定ファイルによる最終的な設定内容の表示:

hg config [-u] [NAME]...

引数指定が無い場合、 全ての設定項目に対して、 名前と値を表示します。

'section.name' 形式に合致する引数を1つだけ指定した場合、 その設定項目 値のみを表示します。

複数の引数が指定された場合、 それらをセクション名とみなし、 該当する セクションの設定項目を全て表示します。

--edit 指定のある場合、 ユーザ毎設定ファイルの編集を開始します。 --global 指定のある場合は、 システムワイド設定ファイルが、 --local 指定のある場合は、 リポジトリ毎設定ファイルが、 編集対象になります。

--debug 指定がある場合、 設定項目毎に記述位置(ファイル名と行番号)が 表示されます。

設定ファイルに関する詳細は hg help config を参照してください。

成功時のコマンド終了値は 0、指定セクション不在時は 1 です。

オプション:

copy

指定されたファイルの複製:

hg copy [OPTION]... [SOURCE]... DEST

対象ファイルが複製元からの複製であることを記録します。 複製先指定が ディレクトリの場合、 ディレクトリ内に複製が作成されます。 複製先指定が ファイルの場合、 複製元は1つしか指定できません。

特に指定が無い場合、 複製元ファイルの内容を持つ複製先ファイルを作業 領域に作成します。 -A/--after 指定がある場合、 「複製」操作は記録され ますが、 ファイルの複製は行われません。

本コマンドの実行結果は次回のコミットの際に効果を発揮します。 複製操作のコミット前取り消しは、 hg help revert を参照して ください。

成功時のコマンドの終了値は 0、 エラー発生時は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: cp

diff

作業領域全体(または指定ファイル)の差分抽出:

hg diff [OPTION]... ([-c REV] | [-r REV1 [-r REV2]]) [FILE]...

指定されたファイルに対して、 リビジョン間の差分を表示します。

差分は unified diff 形式で表示されます。

リビジョン指定が2つの場合、 指定リビジョン間の差分が表示されます。 リビジョン指定が1つの場合、 作業領域が指定リビジョンと比較されます。 リビジョン指定がない場合、 作業領域が第1親リビジョンと比較されます。

指定リビジョンと、 その第1親との間の差分を見るには、 -c/--change で 対象リビジョンを指定する方法も使用できます。

-a/--text 指定が無い場合、 バイナリと思しきファイルは処理対象から 除外されます。 -a 指定が有る場合、 結果に関わらず全てのファイルが 処理対象となります。

git 拡張差分形式で表示するには -g/--git を指定します。 詳細は hg help diffs を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

export

1つ以上のリビジョンに対するヘッダおよび変更内容の出力:

hg export [OPTION]... [-o OUTFILESPEC] [-r] [REV]...

指定リビジョンに対して、 ヘッダ情報および変更内容を表示します。 リビジョン指定が無い場合は、 作業領域の第1親指定とみなします。

ヘッダ情報として表示される情報は:作成者/日付/ (default 以外の場合は)ブランチ名前/ハッシュ値/親リビジョン/コミットログ

出力先指定(置換指定可能)がある場合、 出力はファイルに保存されます。 置換指定として以下のものが使用可能です:

-a/--text 指定が無い場合、 バイナリと思しきファイルは処理対象から 除外されます。 -a 指定が有る場合、 結果に関わらず、 全てのファイルが 処理対象となります。

git 拡張差分形式で出力するには -g/--git を指定します。 詳細は hg help diffs を参照してください。

--switch-parent を指定することで、 比較対象が第2親になります。 これはマージのレビューの際などに有効です。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

files

管理対象ファイルの一覧表示:

hg files [OPTION]... [PATTERN]...

作業領域又は指定リビジョンにおける、 管理対象ファイルを一覧表示します (登録除外されたファイルは、 対象から除外されます)。

パターン指定が無い場合、 本コマンドは構成管理対象下にある作業領域中の 全てのファイル名を表示します。

ファイルの指定方法の詳細に関しては hg help patterns および hg help filesets を参照してください。

パターン合致がある場合のコマンド終了値は 0、 それ以外は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

forget

次回コミットにおける指定ファイルの登録除外:

hg forget [OPTION]... FILE...

指定ファイルの次回コミットにおける登録除外を予約します。

本コマンドでの登録除外は、 現ブランチにおける登録除外のみを意味し、 履歴そのものは保持され続けますし、 作業領域からも削除されません。

作業領域中のファイルを削除する場合は hg remove を使います。

登録除外操作のコミット前取り消しは、 hg help add を参照して ください。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

graft

別ブランチ上から現行ブランチへの指定リビジョンの複製:

hg graft [OPTION]... [-r REV]... REV...

本コマンドは、 あるブランチから別のブランチへ、 Mercurial のマージ機能でリビジョンを複製しますが、 履歴上はマージされません。 これは 'backport' または 'cherry-picking' と呼ばれる機能です。 特に指定の無い場合、 ユーザ名、 日付、 コミットログは、 元リビジョンのものを再利用します。

現行リビジョンの祖先、 既に移植 (graft) 済みのリビジョン、 マージ実施リビジョンは、 複製対象から除外されます。

--log が指定された場合、 以下の形式のコメントがログに付加されます:

(grafted from 移植元リビジョンのハッシュ値)

移植対象リビジョン、 あるいはその移植先リビジョンが、 移植先にとって、 祖先となる場合 (※ 訳注: 前者は直接的、 後者は間接的な祖先) でも、 --force が指定された場合には、 移植が実施されます。 hg backout で打ち消されている移植対象の、 再適用等で有用です。

本コマンドのマージ処理で衝突が検出された場合、 処理が中断されるので、 手動で衝突を解決してください。 全ての衝突が解消されたならば、 -c/--continue 指定により、 未完了の移植を再開してください。

リビジョン指定の詳細は hg help revisions および hg help revsets を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

grep

特定のパターンに合致するファイルとリビジョンの検索:

hg grep [OPTION]... PATTERN [FILE]...

正規表現に合致するファイルを含むリビジョンを検索します。

本コマンドの挙動は Unix の grep とは異なります。 解釈可能な正規表現は Python/Perl 形式のものだけです。 検索対象はリポジトリ内のデータのみで、 作業領域は検索対象には含まれません。 パターンに合致する内容が現れたリビジョンを表示します。

特に指定が無い場合、 本コマンドはパターンに合致する内容が最初に現れた リビジョンを各ファイル毎に表示します。 パターンに合致する変更のあった 全てのリビジョンを表示する場合、 --all を指定します(パターン合致部が 削除操作なら "-"、 追加操作なら "+" が検索結果に表示)。

パターン合致がある場合のコマンドの終了値は 0、 それ以外は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

heads

ブランチヘッドを表示:

hg heads [-ct] [-r STARTREV] [REV]...

引数指定が無い場合、 リポジトリ中の未閉鎖ブランチヘッドを、 全て表示します。 「ブランチヘッド」とは、 同一名前付きブランチ上に、 子リビジョンを持たないリビジョンのことです。 新規の変更内容は、 このようなリビジョンに記録されますので、 update や merge 操作での、 対象として指定される機会が多いです。

1つ以上のリビジョンが指定された場合、 指定リビジョンが属する、 名前付きブランチの、 未閉鎖ブランチヘッドのみを表示します。 例えば hg heads . 実行では、 作業領域が属する名前付きブランチの、 未閉鎖ブランチヘッドにみが表示されます。

-c/--closed 指定時には、 閉鎖済みのブランチ (hg commit --close-branch 参照) も表示されます。

「開始リビジョン」が指定された場合、 指定された開始リビジョンの 子孫となるヘッドのみが表示されます。

-t/--topo 指定時には、 名前付きブランチに関する判定は無視され、 構造的 (topological) ヘッド (子リビジョンを一切持たないリビジョン) が表示されます。

合致するヘッドがある場合のコマンドの終了値は 0、 それ以外は 1 です。

オプション:

help

指定されたトピックのヘルプや、 ヘルプ概要の表示:

hg help [-ecks] [TOPIC]

引数指定が無い場合、 コマンドの一覧と概要を表示します。

トピックやコマンド名が指定された場合、 指定対象のヘルプを表示します。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

identify

作業領域または特定リビジョンの識別情報表示:

hg identify [-nibtB] [-r REV] [SOURCE]

1つまたは2つの親リビジョンのハッシュ値を使用して、 指定リビジョンにおける要約情報を表示します。 親リビジョンハッシュに続けて、 作業領域の変更が未コミットの場合は "+" 、 default 以外のブランチであればブランチ名、 付与されているタグの一覧、 および付与されているブックマークの一覧が表示されます。

リビジョン指定無しで起動された場合は、 作業領域の状態を表示します。

パス指定有りでの起動の際には、 他のリポジトリまたはバンドルファイルの 状態を表示します。

識別用ハッシュ値等を含む、 特定リビジョンの情報参照に関する詳細は、 hg log を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

import

パッチの順次取り込み:

hg import [OPTION]... PATCH...

列挙されたパッチの取り込みおよびコミットを (--no-commit 指定が無い限り) 個別に行います。

標準入力からパッチを取り込むには、 パッチ名に "-" を指定します。 URL が指定された場合、 パッチを当該 URL からダウンロードします。

取り込み作業は作業領域で実施されるため、 未コミット変更がある場合は、 取り込み操作は中断されます (--bypass 指定時除く)。

--bypass 指定時は、 作業領域内容の変更無しに、 履歴に記録します。 --exact 指定が無い場合、 変更は作業領域の親リビジョンに適用されます。

添付ファイル形式 (但し text/plain または text/x-patch 型限定) を含めて、 電子メールからもパッチを取り込めます。 作成者／コミットログが無い場合、 電子メールの From および Subject ヘッダ値を使用します。 差分データに先立つ text/plain パートは、 コミットログに追記されます。

hg export により生成されたパッチを取り込む場合、 電子メールの ヘッダやボディの情報よりも、 パッチに含まれる情報の方が優先します。 コマンドラインでの -m/--message または -u/--user 指定は、 これらよりも更に優先します。

If --exact is specified, import will set the working directory to the parent of each patch before applying it, and will abort if the resulting changeset has a different ID than the one recorded in the patch. This will guard against various ways that portable patch formats and mail systems might fail to transfer Mercurial data or metadata. See hg bundle for lossless transmission.

--partial 指定により、 パッチが部分的にしか適用されない場合でも、 新規リビジョンの生成が保証されます。 適用失敗したパッチ部位は、 対象ファイル.rej ファイルに保存されます。 適用失敗部位の問題を、 手動で解消した上で、 hg commit --amend で取り込むことも可能です。 --partial には、 パッチに含まれるメタデータ情報 (コミットユーザ名、 日付、 コミットログなど) を失うことを回避する目的があります。

-s/--similarity が指定された場合、 hg addremove と同様な方針で、 パッチによる変更結果から、 改名や複製を検出します。

ui.patch 設定により、 外部プログラムでのパッチ適用も可能です。 デフォルトのパッチ適用で使用される Mercurial の内部処理でも、 patch.fuzz 設定により fuzz 挙動を制御可能です。 設定ファイルや、 上記設定項目の詳細に関しては hg help config を参照してください。

-d/--date での日時表記は hg help dates を参照してください。

成功時のコマンド終了値は 0、部分成功時は 1 です (--partial 参照).

オプション:

incoming

指定リポジトリ中の未取り込みリビジョンの検索:

hg incoming [-p] [-n] [-M] [-f] [-r REV]... [--bundle FILENAME] [SOURCE]

ファイルパス、 URL または hg pull の無指定時連携先リポジトリ中の、 未取り込みリビジョンを検索します。 これらのリビジョンは hg pull を実行した際に、 取り込み対象となります。

対象リポジトリの指定形式は hg help pull を参照してください。

BM1               01234567890a 追加
BM2               1234567890ab 更新
BM3               234567890abc 分岐
BM4               34567890abcd 変更

取り込み対象がある場合のコマンド終了値は 0、 それ以外は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: in

init

指定されたディレクトリでの新規リポジトリの作成:

hg init [-e CMD] [--remotecmd CMD] [DEST]

指定されたディレクトリに新規リポジトリを作成します。 指定された ディレクトリが存在しない場合には、 ディレクトリを作成します。

ディレクトリが指定されない場合、 現ディレクトリが初期化されます。

複製先として ssh:// URL 形式を指定することも可能です。 詳細に関しては、 hg help urls を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

locate

指定されたパターンに合致する名前を持つファイルの特定 (非推奨):

hg locate [OPTION]... [PATTERN]...

構成管理対象となるファイルの中から、 指定されたパターンに合致する 名前のファイルを特定します。

特に指定が無い場合、 本コマンドは構成管理対象となる作業領域中の 全ディレクトリを検索対象とします。 現ディレクトリとその配下のみを検索 対象とする場合は "--include ." を指定します。

パターン指定が無い場合、 本コマンドは構成管理対象下にある作業領域中の 全てのファイル名を表示します。

本コマンドの出力を "xargs" コマンドへと渡す場合、 本コマンドと "xargs" コマンドの両方に "-0" を指定してください。 空白文字を 含む単一のファイル名を、 "xargs" が複数のファイル名に解釈して しまう問題は、 このオプションにより解消されます。

より高機能な hg files コマンドのヘルプを参照してください。

パターン合致がある場合のコマンドの終了値は 0、 それ以外は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

log

リポジトリ全体またはファイルの変更履歴の表示:

hg log [OPTION]... [FILE]

特定のファイルまたはリポジトリ全体の変更履歴を表示します。

特に指定されない場合、 対象となるリビジョンの範囲は tip:0 とみなされますが、 --follow が指定された場合は、 作業領域の 親リビジョンが開始リビジョンとみなされます。

ファイルの履歴表示では、 改名／複製時の元ファイルにまでさかのぼった 履歴は表示しません。 元ファイルの履歴をさかのぼる場合は、 ファイル名 と一緒に -f/--follow を使用します。 --follow 指定の際にファイル名が 指定されない場合は、 開始リビジョンに連なるリビジョンのみを表示 します。

特に指定が無い場合、 本コマンドが出力する情報は - リビジョン番号、 識別用ハッシュ値、 タグ、 (リビジョン番号の離れた) 親リビジョン、 作成者、 作成日時およびコミットログの1行目 - です。 -v/--verbose が指定された場合、 変更対象ファイル一覧と、 コミットログの全文も表示されます。

--graph 指定がある場合、 最新リビジョンを上にした履歴グラフ (DAG) を、 ASCII アートで描画します。 履歴グラフにおける 'o' はリビジョン、 '@' は作業領域の親、 'x' は廃止 (obsoleted) リビジョンを意味します。 また '+' は、 同一行の 'o' が '+' 下方のリビジョンを親としたマージで、 且つこのマージによって、 履歴が枝分かれしていることを表します。

-d/--date での日時表記は hg help dates を参照してください。

リビジョン指定の詳細は hg help revisions および hg help revsets を参照してください。

同梱されているスタイルや、テンプレートのカスタマイズ等の詳細は、 hg help templates を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: history

manifest

現時点または指定時点でのリポジトリマニフェストの出力:

hg manifest [-r REV]

指定リビジョンにおける構成管理対象ファイルの一覧を表示します。 リビジョン指定が無い場合、 作業領域の(第1)親リビジョンか、 作業領域の更新前なら null が使用されます。

-v が指定された場合、 ファイルアクセス権やシンボリックリンク、 実行可能ビットといったものも表示されます。 --debug が指定された場合、 各ファイルのリビジョンのハッシュ値が 表示されます。

--all が指定された場合、 リビジョンに関わる全ファイルが表示されます。 この場合、 削除／改名対象ファイルも含まれます。

成功時のコマンド終了値は 0 です。

オプション:

merge

他リビジョンを作業領域にマージ:

hg merge [-P] [[-r] REV]

現時点での作業領域の内容を、 指定されたリビジョンへと至るまでの 共通の親リビジョンからの変更内容とマージします。

両方の親リビジョンに対して差分のあるファイルは、 次回コミットの際には 変更されたものとして記録されますので、 必要以上の変更が実施される前に コミットを実施してください。 このコミット時に生成されるリビジョンは、 親リビジョンを2つ持つリビジョンとなります。

--tool を使用することで、 ファイルのマージに使用するコマンドを指定可能です。 このオプションによる指定は、 HGMERGE 環境変数や設定ファイルによる指定を上書きします。 指定の詳細に関しては、 hg help merge-tools を参照してください。

マージ対象リビジョンの指定が無く、 作業領域の親リビジョンがヘッドで、 且つ現行ブランチがもう1つだけヘッドを持つ場合、 そのヘッドがマージ 対象となります。 それ以外の場合は、 明示的なリビジョン指定が必要です。

衝突の扱いに関する詳細は hg help resolve を参照してください。

コミット前にマージ処理を取り消す場合は、 hg update --clean . が使用できますが、 マージ前の親リビジョンの内容で上書きするため、 作業領域中の全ての変更内容が失われます。

成功時のコマンド終了値は 0、 未解消ファイルがある場合は 1 です。

オプション:

outgoing

連携先リポジトリに含まれないリビジョンの表示:

hg outgoing [-M] [-p] [-n] [-f] [-r REV]... [DEST]

指定された連携先リポジトリ (または、 無指定時の hg push 先リポジトリ) に含まれないリビジョンを表示します。 ここで表示されるリビジョンは、 hg push 実施の際に、 連携先へと反映されます。

有効なリポジトリ指定形式は hg pull を参照してください。

BM1               01234567890a 追加
BM2                            削除
BM3               234567890abc 更新
BM4               34567890abcd 分岐
BM5               4567890abcde 変更

反映可能リビジョンがある場合のコマンド終了値は 0、 それ以外は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: out

parents

作業領域(または指定リビジョン)の親リビジョンの表示 (非推奨):

hg parents [-r REV] [FILE]

作業領域の親リビジョンを表示します。 -r/--rev でのリビジョン指定が ある場合、 指定リビジョンの親リビジョンを表示します。 ファイルが指定 された場合、 (作業領域の親リビジョン、 または --rev 指定のリビジョン 以前のもので)そのファイルを最後に更新したリビジョンを表示します。

本コマンドは以下と等価です (※ 訳注: 2つ目以降は FILE や --rev REV 指定時の挙動に対応します):

hg log -r "p1()+p2()"
hg log -r "p1(REV)+p2(REV)"
hg log -r "max(::p1() and file(FILE))+max(::p2() and file(FILE))"
hg log -r "max(::p1(REV) and file(FILE))+max(::p2(REV) and file(FILE))"

関連情報は hg summary や hg help revsets を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

paths

連携先リポジトリの別名一覧の表示:

hg paths [NAME]

指定されたシンボル名に相当する連携先リポジトリを表示します。 シンボル名が指定されない場合、 全ての別名定義が表示されます。

-q/--quiet が指定された場合、 シンボル名検索の過程における表示は抑止され、 結果表示もシンボル名のみが表示されます。

シンボル定義は、 個人の設定ファイルや /etc/mercurial/hgrc 等の [paths] セクションに記述されます。 作業領域での実行の場合は .hg/hgrc での記述も参照されます。

default および default-push は特別な意味を持ちます。 push/pull の際にコマンド行で連携先リポジトリが指定されない場合、 これらのパスが使用されます。 default-push が設定されている場合、 default-push は hg push で使用され、 default は hg pull で使用されます。 default-push が未設定であれば、 push/pull 共に default を使用します。 リポジトリの複製では、 複製元リポジトリが default として .hg/hgrc に記録されます。

詳細は hg help urls を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

phase

現行フェーズ状態の変更または表示:

hg phase [-p|-d|-s] [-f] [-r] [REV...]

引数無しの場合、 作業領域の親リビジョンのフェーズ名を表示します。

-p/--public、 -d/--draft または -s/--secret が指定された場合、 指定リビジョンのフェーズを指定値に変更します。

-f/--force が指定されない限り、 低い方から高い方へのフェーズ変更は、 実施できません。 フェーズの高低は以下のように定義されています:

public < draft < secret

成功時のコマンドの終了値は 0、 フェーズ状態変更失敗時は 1 です。

(フェーズに関する詳細は、 hg help phases を参照してください)

オプション:

[+] 印付きのオプションは複数回指定可能です

pull

指定リポジトリからの変更履歴の取り込み:

hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE]

連携先リポジトリから手元のリポジトリに変更履歴を取り込みます。

パスや URL で指定される連携先リポジトリ中の、 全てのリビジョンが (-R 指定が無い場合は現在の) リポジトリへの取り込み対象となります。 特に指定が無い場合、 このコマンドによる作業領域の更新はありません。

hg incoming を使用することで、 実際の取り込みをせずに、 hg pull による取り込み対象を確認することができます。 表示された 内容の取り込みを決断したならば、 hg incoming 実行で表示された 最後のリビジョンを -r の引数にして hg pull -r X を実行します。

連携先が省略された場合、 'default' パスが連携先として使用されます。 詳細は hg help urls を参照してください。

ブックマーク名としての . は、 アクティブブックマーク指定と等価です

成功時のコマンド終了値は 0、 作業領域更新により、 衝突未解消ファイルが生じる場合は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

push

指定リポジトリへの変更履歴の反映:

hg push [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]

手元のリポジトリから指定連携先リポジトリに変更履歴を反映します。

これは hg pull と対称的な操作です:連携先リポジトリにおいて、 現リポジトリに対する hg pull を行った場合と同一の効果を持ちます。

特に指定の無い場合、 複数ヘッド状態は、 どのヘッドが妥当なものであるか 混乱するため、 連携先に新規ヘッドが作成される反映は許可されません。 このような場合、 hg push 実施前に、 hg pull および hg merge を実施することをお勧めします。

連携先に存在しない名前付きブランチを新規作成する場合は --new-branch を使用します。 このオプションは、 新規ブランチの作成のみを許可します。

-r/--rev が指定された場合、 指定リビジョンとその祖先のリビジョン群が、 連携先リポジトリへと反映されます。

-B/--bookmark が指定された場合、 指定ブックマークのリビジョンと、 その祖先のリビジョン群、 およびブックマークが、 連携先に反映されます。 ブックマーク名としての . は、 アクティブブックマーク指定と等価です

ssh:// URL 形式の詳細は、 hg help urls を参照してください。 連携先が省略された場合、 'default' パスが連携先として使用されます。

反映成功時のコマンド終了値は 0、 何も反映されなかった場合は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

recover

中断されたトランザクションの取り消し:

hg recover

commit や pull が中断された場合の復旧を行います。

本コマンドは、 操作が中断された際のリポジトリ状態の修復を行います。 本コマンドの実行は、 Mercurial が実行を促した場合のみで十分です。

成功時のコマンド終了値は 0、 修復不要または修復失敗時は 1 です。

remove

次回コミットにおける指定ファイルの登録除外:

hg remove [OPTION]... FILE...

現ブランチでの、 構成管理対象からのファイルの除外を予約します。

指定ファイルは、 次回のコミットで登録除外されます。 コミット前に、 登録除外の取り消しは hg help revert を、 構成管理登録の取り消しは hg forget を参照してください。

成功時のコマンド終了値は 0、 警告検出時は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: rm

rename

ファイルの改名(copy + remove と等価):

hg rename [OPTION]... SOURCE... DEST

改名元の複製として改名先を追加登録し、 改名元を登録除外します。 改名先がディレクトリの場合、 ディレクトリ内に複製が作成されます。 改名先がファイルの場合、 改名元は1つしか指定できません。

特に指定が無い場合、 複製元ファイルの内容を持つ複製先ファイルを作業 領域に作成します。 -A/--after 指定がある場合、 「複製」操作は記録され ますが、 ファイルの複製は行われません。

本コマンドの実行結果は次回のコミットの際に効果を発揮します。 改名 操作のコミット前取り消しは hg help revert を参照してください。

成功時のコマンドの終了値は 0、 エラー発生時は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: move mv

resolve

マージの再実施、 または各ファイルのマージ状況管理:

hg resolve [OPTION]... [FILE]...

未解消の衝突の多くは internal:merge や diff3 などを使用した 非対話的なマージに由来します。 本コマンドは、 hg merge 実行後から hg commit 実行にかけて、 マージに関与するファイルを管理します。 (この際には、 作業領域は２つの親リビジョンを持つ必要があります) マージツール設定の詳細は hg help merge-tools を参照してください。

本コマンドは、 以下の形式で使用されます:

• hg resolve [--tool TOOL] FILE...: 指定ファイルのマージを 再度実施します。 この際には、 直前までの変更内容は破棄されます。 衝突解消済みのファイルに対しては、 マージは再実施されません。 全ての未解消ファイルに適用する場合は --all/-a を指定します。 --tool を使用することで、 ファイルのマージに使用するコマンドを 指定可能です。 このオプションによる指定は、 HGMERGE 環境変数や 設定ファイルによる指定を上書きします。 以前のファイルの内容は、 .orig 拡張子のフィルに保存されます。
• hg resolve -m [FILE]: 指定ファイルを衝突解消済みとみなします (例: 手動での修正後に実施)。 特に指定が無い場合、 全ての未解消 ファイルを解消済みとみなします。
• hg resolve -u [FILE]...: 指定ファイルを衝突未解消とみなします。 特に指定が無い場合、 全ての解消済みファイルを未解消とみなします。
• hg resolve -l: 衝突が検出されたファイルの解消状況を表示します。 一覧表示において U は未解消(Unresolved)を、 R は解消済み(Resolved)を意味します。

成功時のコマンド終了値は 0、 衝突解消失敗がある場合は 1 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

revert

親リビジョンの状態でファイルを復旧:

hg revert [OPTION]... [-r REV] [NAME]...

リビジョン指定が無い場合は、 指定されたファイル／ディレクトリを、 作業領域の親リビジョン時点の内容へと復旧します。 本コマンドは対象ファイルに対して、 状態を「変更無し」とし、 add/remove/copy/rename の実施予定を取り消します。 作業領域が複数の親リビジョンを持つ場合、 いずれかのリビジョンを明示的に指定して下さい。

-r/--rev が指定された場合、 指定されたファイル／ディレクトリを、 指定されたリビジョン時点の内容へと復旧します。 以前の変更内容の一部または全部を、 取り消す用途にも使用できます。 -d/--date での日時表記は hg help dates を参照してください。

復旧前のファイルの内容は、 .orig 拡張子付きファイルに保存されます。 変更前内容の保存は --no-backup で抑止できます。 ui.origbackuppath 設定で、 変更前内容の保存先ディレクトリを、 リポジトリルート相対で、 任意に指定できます。

-d/--date での日時表記は hg help dates を参照してください。

以前のリビジョンでの変更を打ち消す方法に関しては、 hg help backout を参照してください。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

rollback

直前のトランザクションの巻き戻し (要注意) (非推奨):

hg rollback

直前のコミットをやり直す場合は、 rollback の代わりに、極力 hg commit --amend を使用してください。

本コマンドの使用には注意を要します。 巻き戻しは１段階限りで、 巻き戻し後の再実施はできません。 直前のトランザクション時点の、 作業領域状態が復元され、 その時点以後の変更は全て失われます。 但し、 作業領域の内容は変更されません。

トランザクションとは、 コマンド実行による、 新規リビジョンの作成や、 外部からのリビジョンの取り込みといった、 リポジトリ操作を、 ひとまとめにするものです。

本コマンドは、 公開リポジトリでの実行を想定していません。 一旦他の ユーザから hg pull 可能な状態になってしまったなら、 公開リポジトリ でトランザクションを巻き戻しても(既に他のユーザが複製している可能性 があるので)効果を持ちません。 その上、 リポジトリからの情報読み取りに 際して、 競合が発生し得ます。 例えば、 併走している hg pull 処理が 巻き戻しによって失敗してしまう可能性があります。

成功時のコマンド終了値は 0、 巻き戻せるデータが無い場合は 1 です。

オプション:

root

作業領域のルート(最上位)ディレクトリ位置の表示:

hg root

現リポジトリのルートディレクトリ位置を表示します。

成功時のコマンド終了値は 0 です。

serve

独立したウェブサーバの実行開始:

hg serve [OPTION]...

リポジトリ参照と hg pull のための HTTP サーバを起動します。 この HTTP サーバを用いることで、 リポジトリの共有／参照を、 即席で行うことができます。 リポジトリを長期間公開する際には、 通常のウェブサーバの使用をお勧めします。

本コマンドで起動されるサーバは、 アクセス制御が実装されていません。 特に設定が無い場合、 誰もがリポジトリを参照可能で、 且つリポジトリは 誰にも更新できない状態にあります。 web.allow_push 設定を * に設定することで、 誰もがリポジトリに hg push できます。 ユーザ認証が必要な場合は、 通常のウェブサーバを使用してください。

特に指定が無い場合、 サーバはアクセスログを標準出力に、 エラーを標準エラー出力に表示します。 ログをファイルに記録する場合は、 -A/--accesslog や -E/--errorlog で指定します。

サーバに空きポート番号の検出および使用をさせる場合、 ポート番号には 0 を指定します。 この場合、 使用するポート番号が表示されます。

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

status

作業領域のファイル操作状況の表示:

hg status [OPTION]... [FILE]...

作業領域のファイル状態を表示します。 名前(パターン)指定のある場合、 その名前に合致するファイルのみが表示されます。 変更無し(clean)、 無視(ignored)または複製(copy)・改名(rename)の元ファイルに関しては、 それぞれ -c/--clean、 -i/--ignored または -C/--copy が指定されるか、 あるいは -A/--all が指定されない限り表示されません。 いずれの表示対象選択オプションも指定されない場合、 -m -a -r -d -u が指定されたものとみなします。

-q/--quiet 指定がある場合、 -u/--unknown または -i/--ignored が明示的に指定されない限り、 未登録ファイルは表示されません。

1つのリビジョンが指定された場合、 比較元リビジョンとして扱われます。 2つのリビジョンが指定された場合、 両リビジョン間で状態を比較します。 --change 指定を使うことで、 第1親から変更されたファイル一覧を簡単に 表示させることができます。

ファイルの状態を表す記号は以下の通り:

M = 変更有り(Modified)
A = 追加登録予定(Added)
R = 登録除外予定(Removed)
C = 変更無し(Clean)
! = 構成管理対象にも関わらず作業領域にファイルが無い(missing)
? = 構成管理対象外(unknown)
I = 無視(Ignored)
  = 直前に表示される新規登録予定ファイル(A)の複製元

成功時のコマンド終了値は 0 です。

オプション:

[+] 印付きのオプションは複数回指定可能です

別名: st

summary

作業領域状態の概要表示:

hg summary [--remote]

親リビジョン、 ブランチ、 想定コミット結果、 フェーズ、 作業領域更新候補等を含む、 作業領域状態の概要を表示します。

--remote が指定された場合、 default 連携先に対する取り込み／反映に 関する概要も表示します。 この処理には時間を要する場合があります。

成功時のコマンド終了値は 0 です。

オプション:

tag

現リビジョンまたは指定リビジョンへのタグの付与:

hg tag [-f] [-l] [-m TEXT] [-d DATE] [-u USER] [-r REV] NAME...

特定のリビジョンに、 指定された名前を付けます。

タグの用途は、 リポジトリ中の特定リビジョンへの名前付けであり、 リビジョン間での比較や、 重要なリビジョンの参照、 リリース時の分岐点に対する目印、 などの用途に使用できます。 既存タグの改変は、 通常ではできません。 -f/--force の指定が必要です

対象リビジョンが指定されない場合、 作業領域の親リビジョンが、 タグ付けの対象となります。

分散構成管理におけるタグ付けの集約を容易にするために、 構成管理下にある他のファイルと同様に、 タグの情報は ".hgtags" ファイルで管理され、 必要であれば手動での編集も可能です。 これは、 タグ付け操作が、 コミット処理を伴うことを意味します。 ローカルタグは '.hg/localtags' で管理されます (リポジトリ間で共有されることはありません)

タグ付け操作は、 ブランチのヘッドにおいて実施されるのが一般的です。 作業領域の親リビジョンが、 ブランチのヘッドでは無い場合、 hg tag 実行は中断されます。 ヘッド以外のリビジョンにおいて、 タグ付けを実施する場合は、 -f/--force を指定してください。

-d/--date での日時表記は hg help dates を参照してください。

リビジョン特定において、 タグ名はブランチ名よりも優先度が高いので、 既存ブランチと同名のタグの使用は止めましょう。

成功時のコマンド終了値は 0 です。

オプション:

tags

リポジトリ中のタグ一覧の表示:

hg tags

本コマンドは、 通常のタグおよびローカルタグの両方を一覧表示します。 -v/--verbose が指定された場合、 ローカルタグには "local" 表示の 第3のカラムが追加されます。 -q/--quiet 指定時はタグ名のみ表示します。

成功時のコマンド終了値は 0 です。

オプション:

tip

tip リビジョンの表示 (非推奨):

hg tip [-p] [-g]

tip リビジョン (一般には単に tip と表記) とは、 リポジトリにおける、 最新の追加リビジョンです (最新の変更されたヘッドでもあります)

コミットした直後であれば、 生成されたリビジョンが tip となります。 他のリポジトリから変更履歴の取り込みをした直後であれば、 連携先 リポジトリでの tip が現リポジトリの tip となります。 "tip" タグは 特別なタグで、 改名や、 他のリビジョンへの付け替えはできません。

本コマンドは非推奨です。 hg heads を使用してください。

成功時のコマンド終了値は 0 です。

オプション:

unbundle

バンドルファイルの適用:

hg unbundle [-u] FILE...

hg bundle コマンドで生成されたバンドルファイルを適用します。

成功時のコマンド終了値は 0、 衝突未解消ファイルがある場合は 1 です。

オプション:

update

作業領域の内容更新(またはリビジョンの切り替え):

hg update [-c] [-C] [-d DATE] [[-r] REV]

指定されたリビジョン時点の内容で、 作業領域を更新します。 対象リビジョンが指定されない場合、 作業領域と同じ名前付きブランチの、 最新リビジョンで更新した上で、 アクティブブックマークを更新します。 (詳細は hg help bookmarks 参照)

作業領域の親リビジョンを、 指定されたリビジョンに更新します (hg help parents 参照)。

指定リビジョンが、 作業領域の祖先／直系の子孫のいずれでもでない場合、 作業領域の更新は中断されます。 -c/--check が指定された場合、 作業領域中の未コミット変更の有無を確認し、 変更が無かった場合には、 作業領域を指定リビジョンで更新します。

マージ実施を途中で取り消す場合は hg update --clean . を実行してください (マージにおける修正内容は破棄されます)。

作業領域中のファイルを削除する場合は、 リビジョンに null を指定します (hg clone -U と同等)。

特定のファイルだけを以前の状態に戻す場合は、 hg revert [-r リビジョン] ファイル名 を使用してください。

-d/--date での日時表記は hg help dates を参照してください。

成功時のコマンド終了値は 0、 未解消ファイルがある場合は 1 です。

オプション:

verify

リポジトリの整合性検証:

hg verify

現リポジトリの整合性を検証します。

本コマンドは、 リポジトリの整合性に関する広範な検証を行います。 変更履歴・マニフェスト・各構成管理対象ファイルにおけるハッシュ値 およびチェックサム、 相互関連付けおよびインデックス等の整合性が 検証されます。

リポジトリ破損時の復旧に関する詳細は、 以下の URL を参照してください。 https://mercurial-scm.org/wiki/JapaneseRepositoryCorruption

成功時のコマンドの終了値は 0、 エラー発生時は 1 です。

version

バージョンおよび著作権情報の表示:

hg version

バージョンおよび著作権情報の表示

概要

Mercurial では、リポジトリのルート直下に置かれた .hgignore と呼ばれるファイルを使用して、構成管理対象からの ファイルの除外を制御します。

説明

Mercurial の作業領域には、 構成管理対象にしたくないファイルも 多数存在し得ます。 例えば、 エディタの作成するバックアップファイルや コンパイラが生成する中途／最終成果物等です。 作業領域のルート直下に置いた .hgignore ファイルにおいて、 対象ファイルの名前を列挙することで、 これらを無視することができます。 .hgignore は明示的に手動で作成しなければなりません。 一般的には、 このファイルも構成管理対象に含めますので、 履歴の反映や取り込みによって、 設定内容は他のリポジトリにも伝播します。

未登録ファイルが、 作業領域のルートからの相対パス、 またはそのパスの先頭部分が、 .hgignore に記述されたパターンと合致する場合、 そのファイルは Mercurial からは無視されます。

例えば、 未登録ファイル file.c が、 作業領域の a/b/file.c に位置すると仮定します。 a/b/file.c, a/b または a といったパターンが .hgignore に記述されている場合、 Mercurial はこの file.c を無視します。

作業領域毎の無視設定に加えて、 ユーザ毎、 またはシステム毎の 無視設定ファイルを指定することが可能です: これらのファイルの設定に関する詳細は、 hg help config の [ui] セクションにおける ignore 設定キーの説明を参照してください。

既に構成管理下にあるファイルに対して、 Mercurial コマンドの実施要否を制御するには、 多くのコマンドでサポートされている -I および -X の使用が便利です。 詳細に関しては、 hg help <command> および hg help patterns を参照してください。

既に管理対象となっているファイルは、 .hgignore 中の指定が合致しても、 無視の対象とはなりません。 .hgignore 記述により、 管理対象外のファイル X が無視されている場合でも、 明示的な hg add X 実行により、 ファイル X を管理対象にすることが可能です。

文法

無視設定ファイルは、 1行1パターンでパターンが列挙された、 単純なテキストファイルです。 空の行は無視されます。 # 文字はコメント文字、 \ 文字はエスケープ文字として扱われます。

Mercurial の無視設定ファイルでは、 複数のパターン文法を利用できます。 デフォルトの文法は Python/Perl 形式の正規表現です。

文法を変更するには、 以下のような形式の行を記述します:

syntax: NAME

NAME 部分には、 以下のいずれかを記述します:

regexp

Python/Perl 形式の正規表現 (※ 訳注: re でも可)

glob

Shell 形式のパターンマッチ

文法変更の指定は、 次に文法を指定するまでに記述された、 全てのパターンに対して有効です。

glob と regexp のいずれの場合も、 作業領域ルートからの相対パスに対して、 部分一致すれば合致とみなされます。 glob 文法での *.c パターン指定は、 任意のディレクトリにおける .c 拡張子ファイルに合致しますし、 regexp 文法での \.c$ パターン指定も、 同様のファイルに合致します。 ルート直下のファイルにのみ合致させたい場合、 regexp 文法であれば、 パターン記述を ^ で開始してください。

リポジトリルートの .hgignore に subinclude:path/to/subdir/.hgignore 記述を追加することで、 各サブディレクトリ固有の .hgignore 設定が可能です。 subinclude: と include: の詳細は hg help patterns を参照してください。

記述例

無視設定ファイルの記述例を以下に示します。

# Shell 形式パターンマッチ文法を指定。
syntax: glob

*.elc
*.pyc
*~

# 正規表現文法への切り替え。
syntax: regexp
^\.pc/

URL と共通引数

リポジトリ参照 URL 配下のパスは /{command}[/{arguments}] 形式です。 {command} は機能を、 {arguments} は機能に対する引数指定を表します。

ウェブサーバにはデフォルトの表示スタイルがあります。 スタイル定義は、 名前付きテンプレート群をまとめたものです。 個々のテンプレートは、 リビジョン情報や差分など、 表示要素を文字列化します。

ウェブサーバへの要求の際に、 スタイルを指定する方法は2つあります。 {command} がハイフン (-) を含む場合、 ハイフンの前の部分で、 スタイル名を指定します。 例えば /atom-log は log 機能の結果を atom スタイルで文字列化します。 もう一つの指定方法は、例えば /log?style=atom のような、 style クエリ文字列引数での指定です。 推奨される指定方法は、 ハイフンを使用する形式の方です。

スタイルと処理の組み合わせ次第では、 未定義のテンプレートの存在により、 応答が正しく文字列化されない可能性があります。

多くの処理で、 {command} に続く URL パス要素として {revision} を指定できます。 これは処理対象のリビジョンを指定するものです。 多くの場合、 16進12桁の短縮形式ハッシュ値が使用されますが、 hg help revisions 中で説明されている形式は、 概ね機能します。

コマンドと URL

ウェブサーバに指定可能なコマンドと URL 形式を以下に示します:

利用可能なマージツール

外部のマージツールとその実行に関する設定は、 設定ファイルの merge-tools セクションに記述されますが、 設定記述の際の名前には、 外部ツールのコマンド名そのものを使用するが通例です - hgrc(5) を参照してください (※ 訳注: hg help config でも参照可能)。

マージツール設定は、 システム上に実行可能ファイルが存在し、 且つマージ処理が可能である場合に意味を持ちます。 実行可能ファイルの指定は、 絶対または相対パスで指定されるか、 コマンドサーチパス設定上に、 同名の実行可能ファイルが存在する場合に有効となります。 マージツールはマージ処理が可能であるものと仮定されます。 対象がシンボリックリンクで シンボリックリンクが扱える (設定の) 場合、 対象がバイナリファイルで バイナリファイルが扱える (設定の) 場合、 あるいは GUI が必要な設定で GUI が利用可能な場合は、 それぞれ適切に機能することが要求されます。

以下のような内部マージツールも利用可能です:

:dump

作業領域側、 マージ対象リビジョン側、 および共通祖先時点の、 それぞれの内容を持つ3つのファイルを生成します。 これらのファイルは、事後の手動マージ等で使用してください。 対象ファイル名が a.txt であった場合、 生成されるファイルはそれぞれ a.txt.local, a.txt.other および a.txt.base と命名され、 a.txt と同じディレクトリに格納されます。

:fail

変更内容に関するマージ処理は実施せず、 必ずマージ失敗とみなします。 マージ失敗とみなされたファイルに対しては、 hg resolve による手動での衝突解消が必要です。

:local

マージ結果として、 作業領域側 (p1()) の内容を採用します。

:merge

非対話的な、 単純なマージ処理を実施します。 衝突があった場合、 マージ処理は失敗とみなされますが、 マージ結果ファイルには、 衝突マークが記録されます。 マージ対象の2つのリビジョンが、 衝突情報として記録されます。

:merge-local

内部ツール :merge と同様の挙動ですが、 非対話的な衝突解消の際に、 作業領域側 (p1()) の変更内容を採用します。

:merge-other

内部ツール :merge と同様の挙動ですが、 非対話的な衝突解消の際に、 マージ対象リビジョン側 (p2()) の変更内容を採用します。

:merge3

非対話的な、 単純なマージ処理を実施します。 衝突があった場合、 マージ処理は失敗とみなされますが、 マージ結果ファイルには、 衝突マークが記録されます。 マージ対象の２つのリビジョンに加えて、 共通祖先の情報が、 衝突情報として記録されます。

:other

マージ結果として、 マージ対象リビジョン側 (p2()) の内容を採用します。

:prompt

作業領域側 (p1()) とマージ対象リビジョン側 (p2()) のどちらを、 マージ結果として採用するか、 対話的に確認します。

:tagmerge

タグファイル専用のマージ処理を行います (実験的実装)

:union

非対話的な、 単純なマージ処理を実施します。 衝突があった場合、 両方の変更内容が取り込まれます。 衝突マークは記録されません。

内部マージツールは、 常に利用可能で GUI も必要としませんが、 シンボリックリンクやバイナリファイルには対応しません。

マージツールの選択

Mercurial で使用されるマージツールは以下の順序で決定されます:

1. hg merge や hg resolve で --tool が指定された場合、 指定されたツールが使用されます。 merge-tools 設定に記述された名前が指定された場合、 設定内容が適用されます。 それ以外の場合、 指定されたツールは、 実行可能ファイルでなければなりません。
2. HGMERGE 環境変数が設定されている場合、 その内容が適用されますが、 実行可能ファイルが指定されている必要があります。
3. merge-patterns セクションに記述されたパターンに、 マージ対象ファイルの名前が合致した場合、 合致したパターンに対応する最初のマージツールが使用されます。 バイナリファイルへの適用可否設定は考慮されません。
4. ui セクションの merge 設定はこの段階で考慮されます。 指定内容が merge-tools 設定に記述された名前では無い場合、 実行可能ファイルが指定されなければなりません。 それ以外の場合は、 利用可能な設定内容が適用されます。
5. merge-tools 設定に何らかの記述がある場合、 優先度の最も高いツールが使用されます。
6. hgmerge という名前のツールが利用可能な場合はこれが利用されます。 但しシンボリックリンクやバイナリファイルには適用されません。
7. マージ対象ファイルがシンボリックリンクやバイナリファイルでない場合、 内部ツールの :merge が使用されます。
8. ファイルのマージは失敗とみなされ、 手動での hg resolve が必要です。

マージツールの設定詳細に関しては、 hgrc(5) における merge-tools や ui セクションを参照してください。 (※ 訳注: hg help config でも参照可能)

フェーズとは？

フェーズ (phase) は、 当該リビジョンの共有性を管理する仕組みです。 この仕組みによって、 予期せぬ履歴改変 (例: mq や rebase エクステンション等によるもの) を防止できます。

リポジトリ中の各リビジョンは、 以下のいずれかのフェーズに属します:

• public : 公開サーバ上で参照可能なリビジョン
• draft : public 化前段階のリビジョン
• secret : push/pull/clone の対象外となるリビジョン

フェーズには順序関係 (public < draft < secret) があり、 祖先よりも小さなフェーズを持つことはできません。 例えば public フェーズの祖先は、 全て public フェーズです。 各リビジョンのフェーズは、 基本的に public 化する方向に変更されるべきです。

フェーズはどう管理されるのか？

多くの場合、 フェーズは透過的に機能します。 特に指定の無い場合、 新規リビジョンは draft フェーズで作成され、 他リポジトリへの反映の際に public 化されます。

予期せぬ類似リビジョン生成回避のため、 mq/rebase 等のエクステンションは、 一旦 public 化されたリビジョンを、 変更／破棄の対象にできません。 必要であれば hg phase コマンドによる手動でのフェーズ変更も可能です。 実行例に関しては hg help -v phase を参照してください。

以下の記述を設定ファイルに追加することで、 新規コミット時のフェーズを secret に変更できます:

[phases]
new-commit = secret

フェーズとサーバ

特に指定の無い場合、 全てのサーバで publishing が実施されます。 これは以下を意味します:

- draft フェーズのリビジョンは、 pull/clone されたクライアント側では
  public フェーズとみなされる

- クライアントから push された draft フェーズのリビジョンは、
  サーバ／クライアントの両方で public フェーズとみなされる

- secret フェーズのリビジョンは push/pull/clone 対象にならない

未完の作業を共有するために、 リビジョンのフェーズを draft のままで push/pull したい場合もあるでしょう。 publishing を無効化するには、 サーバ側で以下の設定を行ってください:

[phases]
publish = False

設定ファイルに関する詳細は hg help config を参照してください。

記述例

• draft または secret フェーズのリビジョン一覧:

  hg log -r "not public()"
  

• secret フェーズの全リビジョンのを draft 化:

  hg phase --draft "secret()"
  

• 現行リビジョンと子孫のフェーズを public から draft に強制変更:

  hg phase --force --draft .
  

• リビジョン番号とフェーズを表示:

  hg log --template "{rev} {phase}\n"
  

• 連携先リポジトリに応じて、リビジョンを draft フェーズ化:

  hg phase -fd "outgoing(URL)"
  

フェーズの手動操作に関しては hg help phase を参照してください。

インタフェースの選択

機械処理における Mercurial との連携方法には、 以下のような選択肢があります:

• hg コマンドの実行
• HTTP サーバへの問い合わせ
• コマンドサーバの利用

hg コマンドの実行は、 人間が対話シェル経由で利用するのと同じ形態です。 Mercurial 利用者であれば、 既にお馴染みの形態でしょう。

HTTP サーバ機能は hg serve でも起動できます。 通常このコマンドは、 "hgweb" HTTP サーバを起動します。 このサーバは、 JSON 形式のような、 機械可読 (machine-readable) 形式の出力が可能です。 詳細は hg help hgweb を参照してください。

hg serve コマンドは、 「コマンドサーバ」の起動も可能です。 専用プロトコルで接続したクライアントから、 コマンドサーバ上での Mercurial コマンドの実行を依頼できます。 クライアント向けライブラリの詳細を含む、 コマンドサーバの情報は、 https://mercurial.selenic.com/wiki/CommandServer を参照してください。

hg serve ベースの連携方法 (hgweb およびコマンドサーバ) には、 hg コマンド実行での連携と比較して、 効率の高さ等の利点があります。 hg コマンド実行の場合、 コマンド実行毎の Python プロセス起動が、 所要時間に対するオーバヘッドになるためです。

環境変数

hg help environment で説明されているように、 Mercurial の挙動は、 様々な環境変数から影響を受けます。 とりわけ以下に列挙する環境変数は、 出力の機械可読性に、 強い影響を持っています:

HGPLAIN

この環境変数が未設定の場合、 Mercurial の出力は、 文字コード指定や [ui] verbose 設定 (又は --verbose)、 ロケール指定といった、 各種設定情報の影響を受けます。

機械可読性が必要な場合は、 この環境変数を設定した上で hg コマンドを起動することを、 強くお勧めします。

HGENCODING

この環境変数が未設定の場合、 Mercurial が使用するロケールは、 他の環境変数を元に決定されます (※ 訳注: LANGUAGE や LC_ALL 等。 Windows 環境では、 システムのデフォルトロケール設定の影響も受けます)。 確定したロケールが、 出力内容に含まれる文字をサポートしていない場合、 Mercurial は当該文字を適切に出力できません (多くの場合、 当該文字は "?" 等で置き換えられます)。

出力の一貫性を保つ上では、 この環境変数の明示指定をお勧めします。 UNIX 系 OS 上では "utf-8" あたりが妥当と思われます。

HGRCPATH

この環境変数が未設定の場合、 hg help config での手順に沿って、 設定ファイル群が読み込まれます。 ユーザ毎設定や、 システム毎設定も、 読み込み対象に含まれます。

設定内容を完全に制御したい場合、 必要な設定のみが書かれたファイルを、 HGRCPATH で明示的に指定することをお勧めします。 ユーザ毎設定や、 システム毎設定を、 完全に排除したい場合は、 空のファイルやデバイス (/dev/null 等) の指定でも良いでしょう。 なお、ユーザ毎設定や、 システム毎設定は、 ユーザ名設定や、 必須とされるエクステンション設定 (※ 訳注: 例えば largefiles 無効化は、 リポジトリアクセスを阻害します) 等に対して、 予期せぬ影響を生じ得る点に、 留意してください。

コマンド出力の解析

Mercurial との連携では、 コマンド出力の解析や、 データ抽出が必要です。 本節では、 出力解析／データ抽出で必要とされる、 各種手法を説明します。

その他のトピック

revsets

revsets とは、 リビジョン指定のための問い合わせ言語のことです。 Mercurial の履歴情報における、 SQL 的なものと考えてください。 revsets での問い合わせにより、 特定の条件での履歴抽出が可能です。

詳細は hg help revsets を参照してください。

share エクステンション

share エクステンションにより、 複数のローカルリポジトリ間で、 履歴情報を共有できます。 同一由来のリポジトリを複製する際に、 自動的に共有領域を作成することもできます。

share エクステンションは、 ディスク領域や通信帯域の消費を、 大幅に低減できます。 継続的インテグレーション (CI) を行う場合、 このような資源消費の低減は有用です。

詳細は hg help -e share を参照してください。

サブリポジトリの追加

まだ .hgsub が親リポジトリに存在しない場合は、 手動で作成した上で、 履歴管理対象に登録してください。 親リポジトリの作業領域中の任意の場所に、 外部リポジトリを元に、 作業領域を生成 (checkout) してください。 追加対象の外部リポジトリのためのエントリを .hgsub に追加してください。 これ以後、 このサブリポジトリは管理対象となり、 次回のコミットにおいて、 .hgsubstate に状態が記録され、 親リポジトリのリビジョンに対して、 対応付けが行われます。 (※ 訳注: サブリポジトリに関する「構成管理」は、 あくまで 「親リポジトリの各リビジョンが、 サブリポジトリの各リビジョンと、 どう対応するのか？」 という対応付け情報のみです)

サブリポジトリの同期

構成管理下にあるサブリポジトリの作業領域は、 最新状態への自動的な追従が、 行われなくなります。 その代わり、 親リポジトリのリビジョンにおいて、 関連付けが記録されたリビジョンの内容で更新されるようになります。 この挙動により、 親リポジトリ側と一貫性のある状態が維持できます

そのため、 サブリポジトリの作業領域は、 手動で更新する必要があります。 各サブリポジトリの作業領域を、 希望するリビジョンで更新したならば、 親リポジトリにおいて (適宜テストを実施した上で) コミットを実施することで、 新たなリビジョンの組み合わせが記録されます。

サブリポジトリの削除

親リポジトリからサブリポジトリを削除する場合、 対応するエントリを .hgsub から削除した上で、 関連するファイルを削除してください。

Mercurial コマンドとの連携

サブリポジトリ連携先の書き換え

親リポジトリの利用期間中に、 サブリポジトリの連携先が変更された場合、 変更前に親リポジトリで記録されたリビジョンが持つ連携先情報は、 無効となってしまいます。 親リポジトリの hgrc ファイルまたは Mercurial の設定ファイルにおいて、 連携先情報の書き換えルールを定義することで、 この問題を解消可能です。 詳細に関しては hgrc(5) の [subpaths] セクションを参照してください。 (※ 訳注: hg help config でも参照可能)

acl

リポジトリにおけるアクセス制御用のフック集

アクセス制御用フックを使用することで、 pretxnchangegroup や pretxncommit 契機で更新反映を受理した際に、 指定されたブランチやパスに対して、 アクセス (= 改変) の可否を制御できます。

本エクステンションでは、 各リビジョンのコミット実施者 (この情報は、 あまり有益ではありません) の名前ではなく、 フックが実行される環境での、 ログインユーザ名情報をベースに、 アクセス可否が判定されます。

ACL エクステンションのフックは、 hgsh (※ 訳注: contrib 成果物として、 配布されています) のような、制限付きのシェルと併用することで、 push/pull 以外の操作に関して、 ログイン済みユーザに対する抑止を行う、 という様な用途に適しています。 ユーザがログインできる一般的な環境では、 ユーザによって設定が無効化される可能性があるため、 ACL フックでの制限は、 安全とは言えません。 同一アカウントを、 複数人で共有するような場合も、 アクセス元のユーザを特定できないため、 安全とは言えません。

アクセス可否の判定順序は、 以下の通りです:

1. ブランチへの禁止一覧 (acl.deny.branches セクション)
2. ブランチへの許可一覧 (acl.allow.branches セクション)
3. パスへの禁止一覧 (acl.deny セクション)
4. パスへの許可一覧 (acl.allow セクション)

許可／禁止のいずれも、 キー／値の対で設定します。

[hooks]

# コミット実行に制限を掛けたい場合の設定
pretxncommit.acl = python:hgext.acl.hook

# pull push bundle serve 実行に制限を掛けたい場合の設定
pretxnchangegroup.acl = python:hgext.acl.hook

[acl]
# 変更反映元種別が、以下に列挙されている場合のみ、許可／禁止を行い、
# それ以外の場合は、制限を行わない。 指定可能な種別は、http または
# ssh 経由での全アクセスを指す "serve" か、対応するコマンドの
# (ローカルでの)実行に対応する "push" "pull" "bundle" です。
# デフォルト値: serve
sources = serve

[acl.deny.branches]

# いずれのユーザも frozen-branch へのアクセスを禁止:
frozen-branch = *

# bad-user は全てのブランチへのアクセスを禁止:
* = bad-user

[acl.allow.branches]

# branch-a へのアクセスを特定のユーザにのみ許可:
branch-a = user-1, user-2, user-3

# branch-b へのアクセスを一人のユーザにのみ許可:
branch-b = user-1

# super-user は全てのブランチにアクセス可能:
* = super-user

# 全てのユーザは branch-for-tests にアクセス可能:
branch-for-tests = *

[acl.deny]
# acl.allow よりも先に、 本セクションの設定に対して確認が実施されます。
# 合致する設定があった場合、acl.allow セクションの設定は無視されます。
# acl.deny 設定が無い場合、全ユーザにアクセスが許可されます。
# 記述形式: 合致パターン = ユーザ名, ..., @グループ名, ...

# 全ユーザにマッチさせる場合は、値にアスタリスクを指定:
# my/glob/pattern = *

# user6 は全てのファイルに対してアクセス禁止:
** = user6

# グループ "hg-denied" は全てのファイルに対してアクセス禁止:
** = @hg-denied

# 全ユーザに対して "DONT-TOUCH-THIS.txt" はアクセス禁止。
# (他のファイルにアクセス可能なユーザであっても同様)
src/main/resources/DONT-TOUCH-THIS.txt = *

[acl.allow]
# 設定ファイルに acl.allow セクションが無い場合、全ユーザに対して、
# 全アクセスが許可されます。 空の acl.allow セクションは、
# 全ユーザに対して「許可を与えない」ことを意味します。

# ユーザ "doc_writer" は "docs" 配下の任意のファイルにアクセス可能:
docs/** = doc_writer

# ユーザ "jack" とグループ "designers" は "images" 配下の任意の
# ファイルにアクセス可能:
images/** = jack, @designers

# acl.deny で禁止されている "user6" ユーザおよび "hg-denied"
# グループに属するユーザ以外の、全てのユーザに対して
# "resources" 配下の任意のファイルへのアクセスを許可。
# 但し acl.deny で全ユーザにアクセス禁止されている
# src/main/resources/DONT-TOUCH-THIS.txt を除く:
src/main/resources/** = *

.hgtags = release_engineer

[acl.allow.branches]
# 空

[acl.deny.branches]

# 1) ユーザ 'gollum' のみがブランチ 'ring' にコミット可能。
# その他のブランチへの 'gollum' ／他のユーザのコミット可否は変わらず。
ring = !gollum

# 2) グループ 'hobbit' のメンバーみがブランチ 'lake' にコミット可能。
# その他のブランチへの 'hobbit' ／他のユーザのコミット可否は変わらず。
lake = !@hobbit

# ファイルパスによるアクセス禁止も可能:

[acl.allow]
# 空

[acl.deny]
# 3) ユーザ 'gollum' のみが以下のファイルを変更可能。
# 他のファイルの 'gollum' ／他のユーザの改変可否は変わらず。
/misty/mountains/cave/ring = !gollum

automv

Check for unrecorded moves at commit time (EXPERIMENTAL)

This extension checks at commit/amend time if any of the committed files comes from an unrecorded mv.

The threshold at which a file is considered a move can be set with the automv.similarity config option. This option takes a percentage between 0 (disabled) and 100 (files must be identical), the default is 95.

blackbox

リポジトリにおけるイベントの記録(デバッグ用)

Logs event information to .hg/blackbox.log to help debug and diagnose problems. The events that get logged can be configured via the blackbox.track config key.

記述例:

[blackbox]
track = *
# dirty is *EXPENSIVE* (slow);
# each log entry indicates `+` if the repository is dirty, like :hg:`id`.
dirty = True
# record the source of log messages
logsource = True

[blackbox]
track = command, commandfinish, commandexception, exthook, pythonhook

[blackbox]
track = incoming

[blackbox]
# 記録先ファイルの最大サイズ
maxsize = 1.5 MB
# 記録先ファイルサイズが上限を超えた場合の最大ローテート数
maxfiles = 3

hg blackbox [OPTION]...

bugzilla

Bugzilla バグ管理システムとの連携用フック集

本エクステンションのフックは、 記録されたリビジョンからの Bugzilla バグ ID 検出を契機に、 Bugzilla 上のバグ情報に対して、 コメントを追加します。 Mercurial のテンプレート機能を使うことで、 コメント形式を変更可能です。

コミットログからのバグIDの抽出では、 Bugzilla の「作業時間」を更新する、 所要時間情報の取り出しも可能です (オプション)。 バグ状態を「解決済み」 にすることも可能です。

Bugzilla との連携方式は、 以下の3種類から選択できます:

1. Bugzilla XMLRPC インタフェースを使用。 Bugzilla 3.4 以降が必要。
2. データの確認に Bugzilla XMLRPC を、 コメントの追加に Bugzilla メールインタフェースを使用。 Bugzilla 3.4 以降が必要。
3. Bugzilla データベースを直接操作。 MySQL を使用する Bugzilla 限定。 Python MySQLdb が必要。

データベースの直接操作での連携は、 スキーマ変更の影響を受け易く、 且つ、 コメント追加通知のメール送信に、 寄贈扱い (contrib) の Bugzilla スクリプトを必要とします。 Mercurial の実行ユーザの権限がそのまま、 このスクリプトの実行権限となりますが、 Bugzilla の稼動ホスト上での実行で、 且つ Bugzilla の設定ファイルの読み出し権限を持っている必要があります。 それに加えて、 Bugzilla データベースに対して、 フルアクセス可能な MySQL ユーザの、 ユーザ名とパスワードが必要となります。 以上の条件から、 この連携方式は、 現在は非推奨であり、 Bugzilla の更新にも対応しません。 この連携方式では、 コメントの追加のみがサポートされています。

XMLRPC 連携では、 Bugzilla ユーザ名とパスワードを設定ファイルに記述し、 当該ユーザの権限でコメントが追加されます。 ユーザ名とパスワードは、 当該リポジトリ上で Mercurial を実行する、 全ユーザから参照可能なため、 コメント追加に必要な権限しか持たない、 Bugzilla 連携専用ユーザで、 運用する事を推奨します。 バグの状態を「解決済み」 (fixed) にするには、 Bugzilla 4.0 版以降が必要です。

XMLRPC/email 連携では、 Bugzilla への問い合わせに XMLRPC を使用しますが、 バグへのコメント追加には、 メールを使用します。 メールの From 欄には、 各リビジョンに記録されたユーザ情報中の、 メールアドレスが使用されるため、 各リビジョンの作成者によって、 コメントが追加されたように見えます。 リビジョンのメールアドレス情報が、 Bugzilla ユーザのものと対応しない場合、 Bugzilla へのアクセスで使用されるユーザ名で、 メールが送信されます。 サポート対象の全ての版の Bugzilla で、 バグの状態を「解決」にできます。

全連携方式で共通の設定項目は以下の通りです:

bugzilla.version

連携方式の選択。 指定可能な値は以下の通り:

xmlrpc:	Bugzilla XMLRPC 経由での連携
xmlrpc+email:	Bugzilla XMLRPC とメール経由での連携
3.0:	MySQL 経由での連携: Bugzilla 3.0 以降限定
2.18:	MySQL 経由での連携: Bugzilla 2.18 以上 3.0 未満限定
2.16:	MySQL 経由での連携: Bugzilla 2.16 以上 2.18 未満限定

bugzilla.regexp

状態更新対象のバグID群を、 コミットログから抽出するための正規表現。 非数値文字で区切られたバグID群に合致する <ids> 名のグループ記述 ( "()") が必須です。 バグに対する作業時間を表す、 小数点数に合致する <hours> 名グループも記述可能です。 名前付きグループ記述が無い場合、 最初の "()" グループがバグID群に、 作業時間の更新は無し、 とみなされます。 デフォルトの正規表現は Bug 1234, Bug no. 1234, Bug number 1234, Bugs 1234,5678, Bug 1234 and 5678 および類似の形式に加えて、 前置詞に h または hours が付けられた時間数 (例: hours 1.5) が続くものに合致します。 文字大小は無視されます。

bugzilla.fixregexp

「解決済み」化するバグID群を、 コミットログから抽出するための正規表現。 非数値文字で区切られたバグID群に合致する <ids> 名のグループ記述 ( "()") が必須です。 バグに対する作業時間を表す、 小数点数に合致する <hours> 名グループも記述可能です。 名前付きグループ記述が無い場合、 最初の "()" グループがバグID群に、 作業時間の更新は無し、 とみなされます。 デフォルトの正規表現は、 Fixes 1234, Fixes bug 1234, Fixes bugs 1234,5678, Fixes 1234 and 5678 および類似の形式に加えて、 前置詞に h または hours が付けられた時間数 (例: hours 1.5) が続くものに合致します。 文字大小は無視されます。

bugzilla.fixstatus

バグを「解決」状態にする際の「状態」値。 デフォルト値: RESOLVED (対象済み)

bugzilla.fixresolution

バグを「解決」状態にする際の「対処方法」値。デフォルト値: FIXED (修正済み)

bugzilla.style

コメントの整形に使用するスタイルファイル。

bugzilla.template

コメントの整形に使用するテンプレート。 スタイルファイル指定よりも、 こちらが優先します。 通常のものに加えて、 以下のキーワードが使用できます:

{bug}:	Bugzilla のバグ ID
{root}:	Mercurial リポジトリのフルパス
{webroot}:	Mercurial リポジトリのスラッシュ除外 (strip) 後パス
{hgweb}:	Mercurial リポジトリの URL 生成用のベース URL

無指定の場合、 リポジトリ {root} のリビジョン {node|short} がバグ {bug} に関連。\n詳細:\n\t{desc|tabindent} が使用されます。

bugzilla.strip

テンプレートにおける {webroot} 相当を得るために、 Mercurial リポジトリのパス (テンプレートの {root} 相当) 冒頭から、 取り除くスラッシュの数。 例えば {root} が /var/local/my-project のリポジトリで、 {webroot} を my-project にするためには、 strip に 2 を指定します。 デフォルト値は 0。

web.baseurl

Mercurial リポジトリの URL 生成用ベース URL。 テンプレートキーワード {hgweb} で参照可能。

連携方式 XMLRPC+email と MySQL で共通の設定項目は以下の通りです:

bugzilla.usermap

Mercurial の各リビジョンの、 生成者情報のメールアドレスと、 Bugzilla ユーザのメールアドレスの、 対応一覧ファイルへのパス。 対象ファイルは、 1行1対応付けの、 以下の形式で記述してください:

リビジョン作成者 = Bugzilla ユーザ

[usermap] セクションの説明も参照してください。

[usermap] セクションは、 Mercurial の各リビジョンの、 生成者情報のメールアドレスと、 Bugzilla ユーザのメールアドレスの、 対応付けを行います。 bugzilla.usermap 設定の説明も参照してください。 記述形式は リビジョン生成者 = Bugzilla ユーザ です。

XMLRPC 連携固有の設定項目は以下の通りです:

bugzilla.bzurl

アクセス先 Bugzilla のベース URL。 デフォルト値は http://localhost/bugzilla 。

bugzilla.user

Bugzilla との XMLRPC 連携で、 ログインに使用するユーザ名。 デフォルト値は bugs 。

bugzilla.password

Bugzilla 連携で、 ログインに使用するパスワード。

XMLRPC+email 経由での連携では、 XMLRPC 経由連携に関する設定に加えて、 以下の設定が必要です:

bugzilla.bzemail

Bugzilla へ送信する際の宛先メールアドレス。

以上の設定に加えて、 Mercurial のメール設定も必要です。 hgrc(5) ドキュメント (※ 訳注: hg help config でも参照可能) の [email] および [smtp] セクションを参照してください。

MySQL 経由連携固有の設定項目は以下の通りです:

bugzilla.host

Bugzilla データベースを持つ MySQL サーバのホスト名。 デフォルト値は localhost 。

bugzilla.db

MySQL における Bugzilla データベースの名前。 デフォルト値は bugs 。

bugzilla.user

MySQL サーバへのアクセスに使用するユーザ名。 デフォルト値は bugs 。

bugzilla.password

MySQL サーバへのアクセスに使用するパスワード。

bugzilla.timeout

データベース接続のタイムアウト指定 (単位:秒)。 デフォルト値は 5。

bugzilla.bzuser

リビジョン生成者名が、 Bugzilla ユーザと対応しない場合に、 コメント追加に使用する Bugzilla ユーザ名 (予備設定)

bugzilla.bzdir

Bugzilla のインストール先ディレクトリ。 デフォルトの notify 設定において使用されます。 デフォルト値は /var/www/html/bugzilla 。

bugzilla.notify

バグ情報の更新通知を、 Bugzilla にメール送信させるコマンド。 3つのキーワード bzdir, id (バグ ID) および user (リビジョン作成者の Bugzilla メールアドレス) が、 置換指定可能です。 デフォルト値は MySQL のバージョンに依存しており、 2.18 版以降では、 "cd %(bzdir)s && perl -T contrib/sendbugmail.pl %(id)s %(user)s" が使用されます。

エクステンションの有効化:

[extensions]
bugzilla =

[hooks]
# リビジョンが当該リポジトリに push/pull で取り込まれた契機で
# Bugzilla 連携のフックを実行
incoming.bugzilla = python:hgext.bugzilla.hook

設定例:

以下は XMLRPC 連携の設定例です。 http://my-project.org/bugzilla の Bugzilla と連携し、 ユーザ名 bugmail@my-project.org, パスワード plugh でログインします。 URL http://my-project.org/hg 配下でアクセスする、 /var/local/hg/repos/ 配下の複数リポジトリでの、 設定共有を想定しています:

[bugzilla]
bzurl=http://my-project.org/bugzilla
user=bugmail@my-project.org
password=plugh
version=xmlrpc
template=Changeset {node|short} in {root|basename}.
         {hgweb}/{webroot}/rev/{node|short}\n
         {desc}\n
strip=5

[web]
baseurl=http://my-project.org/hg

以下は XMLRPC+email 連携の設定例です。 http://my-project.org/bugzilla の Bugzilla と連携し、 ユーザ名 bugmail@my-project.org, パスワード plugh でログインします。 URL http://my-project.org/hg 配下でアクセスする、 /var/local/hg/repos/ 配下の複数リポジトリでの、 設定共有を想定しています。 コメントの追加は、 Bugzilla のメールアドレス bugzilla@my-project.org 宛に送信されます:

[bugzilla]
bzurl=http://my-project.org/bugzilla
user=bugmail@my-project.org
password=plugh
version=xmlrpc+email
bzemail=bugzilla@my-project.org
template=Changeset {node|short} in {root|basename}.
         {hgweb}/{webroot}/rev/{node|short}\n
         {desc}\n
strip=5

[web]
baseurl=http://my-project.org/hg

[usermap]
user@emaildomain.com=user.name@bugzilladomain.com

以下は MySQL 連携の設定例です。 /opt/bugzilla-3.2 にインストールされた Bugzilla 3.2 を想定しています。 MySQL サーバのホスト名が localhost, Bugzilla データベース名が bugs, MySQL サーバへのアクセスに、 ユーザ名 bugs, パスワード XYZZY を使用します。 URL http://my-project.org/hg 配下でアクセスする、 /var/local/hg/repos/ 配下の複数リポジトリでの、 設定共有を想定しています:

[bugzilla]
host=localhost
password=XYZZY
version=3.0
bzuser=unknown@domain.com
bzdir=/opt/bugzilla-3.2
template=Changeset {node|short} in {root|basename}.
         {hgweb}/{webroot}/rev/{node|short}\n
         {desc}\n
strip=5

[web]
baseurl=http://my-project.org/hg

[usermap]
user@emaildomain.com=user.name@bugzilladomain.com

上記設定例で Bugzilla に追加されるコメントは、 全て以下の形式となります:

Changeset 3b16791d6642 in repository-name.
http://my-project.org/hg/repository-name/rev/3b16791d6642

(※ ここには各リビジョンのコミットログが展開されます)

censor

指定リビジョンのファイル内容の検閲／消去

censor コマンドは、 指定リビジョン時点における、 指定ファイルの内容を、 消去しますが、 当該リビジョンの ハッシュ値は変えない 点が特徴です。 ハッシュ値が変わらないため、 既存の履歴の有効性は維持したままで、 消去されたデータが clone/pull 等で伝搬することを防止できます。

censor コマンドによる検閲／消去が、 必要とされる典型的なケースは、 以下のようなデータの扱いで、 セキュリティ的／法的に必要とされるケースです:

* パスワード、秘密鍵、暗号化情報
* 有効期限の切れたライセンスにひも付いた、データ／プログラム／ライブラリ
* 個人識別情報、あるいはそれに類する個人情報

検閲によって消去されたファイル内容は、 参照することができなくなります。 hg cat や hg revert 等のコマンドは、 単純に処理が中断されます。 hg verify や hg update 等の場合、 検閲済みのファイルを無視して、 処理を継続することもできます。 検閲済みファイルによる中断を回避するには、 [censor] policy=ignore を設定してください。

hg censor -r REV [-t TEXT] [FILE]

chgserver

command server extension for cHg (EXPERIMENTAL)

'S' channel (read/write)

propagate ui.system() request to client

'attachio' command

attach client's stdio passed by sendmsg()

'chdir' command

change current directory

'getpager' command

checks if pager is enabled and which pager should be executed

'setenv' command

replace os.environ completely

'setumask' command

set umask

'validate' command

reload the config and check if the server is up to date

[chgserver]
idletimeout = 3600 # seconds, after which an idle server will exit
skiphash = False   # whether to skip config or env change checks

children

子リビジョン表示のコマンド (非推奨)

本エクステンションは非推奨です (hg log -r "children(REV)" で代替可能)

hg children [-r REV] [FILE]

hg children => hg log -r "children()"
hg children -r REV => hg log -r "children(REV)"

churn

変更履歴の統計情報表示のコマンド

hg churn [-d DATE] [-r REV] [--aliases FILE] [FILE]

# ユーザ毎の変更行数の表示
hg churn -t "{author|email}"

# 日毎の活発度(コミット実施数)を表示
hg churn -f "%H" -s -c

# 月毎の活発度を表示
hg churn -f "%Y-%m" -s -c

# 年毎の変更行数を表示
hg churn -f "%Y" -s

<別名> = <実名>

clonebundles

advertise pre-generated bundles to seed clones

"clonebundles" is a server-side extension used to advertise the existence of pre-generated, externally hosted bundle files to clients that are cloning so that cloning can be faster, more reliable, and require less resources on the server.

Cloning can be a CPU and I/O intensive operation on servers. Traditionally, the server, in response to a client's request to clone, dynamically generates a bundle containing the entire repository content and sends it to the client. There is no caching on the server and the server will have to redundantly generate the same outgoing bundle in response to each clone request. For servers with large repositories or with high clone volume, the load from clones can make scaling the server challenging and costly.

This extension provides server operators the ability to offload potentially expensive clone load to an external service. Here's how it works.

1. A server operator establishes a mechanism for making bundle files available on a hosting service where Mercurial clients can fetch them.
2. A manifest file listing available bundle URLs and some optional metadata is added to the Mercurial repository on the server.
3. A client initiates a clone against a clone bundles aware server.
4. The client sees the server is advertising clone bundles and fetches the manifest listing available bundles.
5. The client filters and sorts the available bundles based on what it supports and prefers.
6. The client downloads and applies an available bundle from the server-specified URL.
7. The client reconnects to the original server and performs the equivalent of hg pull to retrieve all repository data not in the bundle. (The repository could have been updated between when the bundle was created and when the client started the clone.)

Instead of the server generating full repository bundles for every clone request, it generates full bundles once and they are subsequently reused to bootstrap new clones. The server may still transfer data at clone time. However, this is only data that has been added/changed since the bundle was created. For large, established repositories, this can reduce server load for clones to less than 1% of original.

To work, this extension requires the following of server operators:

• Generating bundle files of repository content (typically periodically, such as once per day).
• A file server that clients have network access to and that Python knows how to talk to through its normal URL handling facility (typically an HTTP server).
• A process for keeping the bundles manifest in sync with available bundle files.

Strictly speaking, using a static file hosting server isn't required: a server operator could use a dynamic service for retrieving bundle data. However, static file hosting services are simple and scalable and should be sufficient for most needs.

Bundle files can be generated with the hg bundle command. Typically hg bundle --all is used to produce a bundle of the entire repository.

hg debugcreatestreamclonebundle can be used to produce a special streaming clone bundle. These are bundle files that are extremely efficient to produce and consume (read: fast). However, they are larger than traditional bundle formats and require that clients support the exact set of repository data store formats in use by the repository that created them. Typically, a newer server can serve data that is compatible with older clients. However, streaming clone bundles don't have this guarantee. Server operators need to be aware that newer versions of Mercurial may produce streaming clone bundles incompatible with older Mercurial versions.

A server operator is responsible for creating a .hg/clonebundles.manifest file containing the list of available bundle files suitable for seeding clones. If this file does not exist, the repository will not advertise the existence of clone bundles when clients connect.

The manifest file contains a newline ( ) delimited list of entries.

Each line in this file defines an available bundle. Lines have the format:

<URL> [<key>=<value>[ <key>=<value>]]

That is, a URL followed by an optional, space-delimited list of key=value pairs describing additional properties of this bundle. Both keys and values are URI encoded.

Keys in UPPERCASE are reserved for use by Mercurial and are defined below. All non-uppercase keys can be used by site installations. An example use for custom properties is to use the datacenter attribute to define which data center a file is hosted in. Clients could then prefer a server in the data center closest to them.

The following reserved keys are currently defined:

BUNDLESPEC

A "bundle specification" string that describes the type of the bundle.

These are string values that are accepted by the "--type" argument of hg bundle.

The values are parsed in strict mode, which means they must be of the "<compression>-<type>" form. See mercurial.exchange.parsebundlespec() for more details.

hg debugbundle --spec can be used to print the bundle specification string for a bundle file. The output of this command can be used verbatim for the value of BUNDLESPEC (it is already escaped).

Clients will automatically filter out specifications that are unknown or unsupported so they won't attempt to download something that likely won't apply.

The actual value doesn't impact client behavior beyond filtering: clients will still sniff the bundle type from the header of downloaded files.

Use of this key is highly recommended, as it allows clients to easily skip unsupported bundles. If this key is not defined, an old client may attempt to apply a bundle that it is incapable of reading.

REQUIRESNI

Whether Server Name Indication (SNI) is required to connect to the URL. SNI allows servers to use multiple certificates on the same IP. It is somewhat common in CDNs and other hosting providers. Older Python versions do not support SNI. Defining this attribute enables clients with older Python versions to filter this entry without experiencing an opaque SSL failure at connection time.

If this is defined, it is important to advertise a non-SNI fallback URL or clients running old Python releases may not be able to clone with the clonebundles facility.

Value should be "true".

Manifests can contain multiple entries. Assuming metadata is defined, clients will filter entries from the manifest that they don't support. The remaining entries are optionally sorted by client preferences (experimental.clonebundleprefers config option). The client then attempts to fetch the bundle at the first URL in the remaining list.

Errors when downloading a bundle will fail the entire clone operation: clients do not automatically fall back to a traditional clone. The reason for this is that if a server is using clone bundles, it is probably doing so because the feature is necessary to help it scale. In other words, there is an assumption that clone load will be offloaded to another service and that the Mercurial server isn't responsible for serving this clone load. If that other service experiences issues and clients start mass falling back to the original Mercurial server, the added clone load could overwhelm the server due to unexpected load and effectively take it offline. Not having clients automatically fall back to cloning from the original server mitigates this scenario.

Because there is no automatic Mercurial server fallback on failure of the bundle hosting service, it is important for server operators to view the bundle hosting service as an extension of the Mercurial server in terms of availability and service level agreements: if the bundle hosting service goes down, so does the ability for clients to clone. Note: clients will see a message informing them how to bypass the clone bundles facility when a failure occurs. So server operators should prepare for some people to follow these instructions when a failure occurs, thus driving more load to the original Mercurial server when the bundle hosting service fails.

color

コマンド出力のカラー化

本エクステンションは、 Mercurial コマンドの出力をカラー化します。 例えば、 diff コマンドでは、 追加行は緑、 削除行は赤といった色付けが、 status コマンドでは、 変更状態のファイルが赤紫 (magenta) で表示されます。 他の多くのコマンドの出力も、 同様にカラー化されます。 カラー化設定は、 カスタマイズ可能です。