Mercurial(hg) を使って GitHub に Pull Request する手順

概要

分散バージョン管理ツールとして自分は「Mercurial」を利用している。
自分にとって Git は難しすぎるので、できれば使いたくなかったので、Git を利用しないで GitHub に Pull Request する方法を調べた。

Pull Request が初めての場合

Pull Request が初めての場合、GitHub の公式マニュアルに従って練習すると良い。Pull Requestのマニュアルは「Fork A Repo · github:help」にある。

GitHub のマニュアルに従って、「https://github.com/octocat/Spoon-Knife」を Fork して練習する。失敗しても誰も怒ったりしないので、自由にやるのが良い。

hg-git のインストールと設定

hg で GitHub のソースを clone するには「hg-git」を利用する。
「hg-git」は Git のバイナリがなくても、単体で Git レポジトリを扱うことができるライブラリ。pip 等で簡単にインストールできる。

pip install hg-git

hgrcに以下を設定する

[extensions]
hggit=

hg で GitHub のソースを clone する

hg-git を利用して GitHub のレポジトリを clone する。
例えばGitHub で「git@github.com:username/Spoon-Knife.git」のようなレポジトリの場合、以下のように指定すると clone できる。

hg clone git+ssh://github.com/username/Spoon-Knife.git

Pull Request用に開発

master でそのまま開発すると、fork 元の変更に追随することができなくなるので、開発用の branch を作成する。

cd Spoon-Knife
hg branch 'develop'
# コミット
hg ci -m"develop"
# 確認
hg branches

そして、開発用の branch から pull request 用の branch を作成する。

hg branch 'feature/samplespike'
# コミット
hg ci -m"feature/samplespike"
# 確認
hg branches

pull request 用の branch で開発する。

push 用の bookmark 作成

hg-git では hg の bookmark が Git の branch になる。push を本当にする場合、bookmark を作成する。

hg bookmark -r feature/samplespike pullrequest/samplespike

pull requestのために、Commit を一つに纏める

開発によって、Commit が複数に分割されている場合があるが、分割されたpull request はしない方が良い。
Git の場合 rebase でこれを実施するが、hg では「Histedit Extension」を利用する。Mercurial 2.3以降は標準添付なので以下のようにhgrcに設定する。

[extensions]
histedit=

利用しているバージョンが Mercurial 2.3 以下の場合は「histedit」からソースを取得して設定する必要がある。

hg clone https://bitbucket.org/durin42/histedit

ソースからの場合は hgrc に以下のように設定する。

[extensions]
histedit = /path/to/hg_histedit.py

histedit の使い方は「hg help -e histedit」でhg の help を見ると和訳されている。
英語だが公式のマニュアルを見ても良い「Histedit Extension」。

hg histedit まとめたいバージョン

push の前に確認する

「hg log」や「hg glog」を利用して意図した通りになっているか十分確認する。push するとhisteditでの変更ができない。

Hg-Gitプラグインは「--HG--」のようなコメントを挿入してしまう。これを抑止するにはソースを直接修正するしかない。
「hggit/git_handler.py」に該当部分が存在するので、気になる場合は、削除かコメントアウトしておくと良い。

push して pull request

hg-git でpush するのは hg で push するのと何も変らない。

hg push

あとは GitHub のWeb から該当の branch を pull request すれば良い。

本家に追随する

本家が自分のpull requestを取り込みしてくれたら、追随する必要がある。

hg pull -r master git+ssh://github.com/octocat/Spoon-Knife.git
hg up

これで取り込める。master に commit していると面倒なことになるので、master では開発しないようにした方が良い。

まとめ

これでGitHub の pull request が hg で可能になる。

Mercurial(hg)で無関係なリボジトリをマージする

概要

Mercurial(hg)を利用しいて、無関係なリボジトリをマージしたくなる場合があります。
例えば、リボジトリを二つ作成したが一つの方が適切だったとか、オープンソースのある成果を取り込みたい、等様々な場面が考えられます。
Mercurial(hg)では無関係なリボジトリをマージすることも可能です。

手順

「hg pull -f」のように「-f」を付与するのがポイントです。

mkdir myrepo1
hg init myrepo1
mkdir myrepo2
hg init myrepo2
echo "aaaa" > myrepo1/hello.txt
hg add myrepo1/hello.txt
echo "bbbb" > myrepo2/hello.txt
hg add myrepo2/hello.txt
hg ci myrepo1 -m"myrepo1"
hg ci myrepo2 -m"myrepo2"
cd myrepo1
hg pull -f ../myrepo2
hg heads
hg merge tip

あとは普段のマージ作業と同じになります。

まとめ

無関係なリボジトリをマージできる事を知らないと、そもそもやろうとしないかもしれませんが、これは知っているとかなり便利です。
いろいろ活用範囲があるでしょう。

Mercurial(hg)で過去のコミットメッセージを修正する

過去のコミットログを修正したい場合は mq を利用して修正します。
設定ファイルで mq を有効にしておきます。

[extensions]
mq =

r 1 のログを変更したい場合は以下の手順で変更できます。
これで"change" というコメントになります。

hg qimport -r 1:tip
hg qapplied
hg qgoto 1.diff
hg qrefresh -m"change"
hg qpush -a
hg qfinish -a

mq を利用するといろいろと過去の修正はできます。

hgflowを試してみる

hgflow の説明と使い方は「hgflow - watawata日記」を参照。
hgflow は Fork した物の方を利用している。yujiewu / hgflow / overview — Bitbucket

curl -LO https://bitbucket.org/yujiewu/hgflow/downloads/hgflow-v0.9.2.tar.gz2
tar xvfj hgflow-v0.9.2.tar.bz2

解凍すると、hgflow.py をいうファイルができる。任意にディレクトリに配置して、${HOME}/.hgrc に以下を設定すると利用できるようになる。

[extensions]
flow = /path/to/hgflow.py

とりあえずこんな感じで動作させてみる。

hg flow init
hg flow develop
hg flow feature start spam
hg flow feature finish spam
hg flow release start 1.0
hg flow release finish 1.0

感想としては、使い易い。
場合にもよるが、git-flow の場合は feature は削除されるので、hgflow も feature は branch でなくて、bookmark の方が良いような気がする。本当は選択できるのが良いのだけど、このあたりはポリシーの問題のような気がする。

convert と filemap を利用した hg リポジトリの分割と統合

リポジトリの分割や統合を実施したい場合があります。 これは hg convert --filemap を利用します。

分割は以下の例です。ポイントは filemap に書く内容で、 include 、 exclude 、 rename があります。この例では各ディレクトリのみ include していますが、複数のディレクトリを include して分割なんてこともできます。

rename の名前でカレントディレクトリに リポジトリが作成されます。元のリポジトリが壊れるわけではありませんが、注意して作業してください。

また分割が終了したら hg update を忘れないでください。

% mkdir -p repo/foo repo/bar
% cd repo
% hg init
% ls -FA
.hg/ bar/ foo/
% ls -R repo
bar foo

repo/.hg/store:

repo/bar:

repo/foo:

% echo "include foo\nrename foo ." > map-foo.txt
% echo "include bar\nrename bar ." > map-bar.txt
% hg convert --filemap map-foo.txt repo foo
% hg convert --filemap map-bar.txt repo bar
% ls -AF foo bar
bar:
.hg/

foo:
.hg/
% cd bar
% hg update
% cd ../foo
% hg update

統合は以下のようにします。bar を foo のサブディレクトリとして統合してみます。

% ls -AF foo bar
bar:
.hg/

foo:
.hg/
% echo "rename . bar" > map-sub.txt
% hg convert --filemap map-sub.txt bar foo
% cd foo
% hg update

log を引き継いで統合されます。

hg st や hg diff のColor表示

.hgrc 等に以下を記述すると全体的に色がつきます。

[extensions]
color=

これは Color Extension を設定しています。基本的にはこれでほとんどの場合で色が付与されます。

色のカスタマイズをしたければ .hgrc に以下のように色設定を書きます。

[color]
status.added = green bold
diff.deleted = red

細かい設定は Color Extension に記述があります。

これで hg st や hg diff で色が表示されます。

ただ hg diff などは長くなって less をしたくなるでしょうが、less -r しても色は付きません。

Mac OS X 10.6 等の場合は .bash_profile にでも以下のような alias を設定すると良いでしょう。

alias -g V="| /usr/share/vim/vim72/macros/less.sh"

以下のように利用します。

hg diff V

V を付与すると Vim の less.sh マクロの効果で色が付いて表示されます。操作感は less と同じになります。