釣りなう(ぉ
git nowでのコミットをディレクトリの変更を wait_on コマンドで検知して、保存時に自動的にやってもらおうというだけだったりする。
ビルド成功時のみ?
テストが成功したら?
なにそれおいしいの?
トピックブランチに入ったら、管理するファイルを生成して以下のスクリプトに管理するファイル名を渡して実行しておけば、ファイル保存時に勝手にgit nowしてくれるという感じ。
#!/bin/bash git_now_loop () { git add -u git now sleep 1 } echo 'Managed files is' if [ $# -eq 0 ]; then echo `git ls-files` while : do wait_on `find . -type d ! -path '*/.git' -and ! -path '*/.git/*' -print` git_now_loop done else echo $@ while : do wait_on $@ git_now_loop done fi
Linuxでは wait_on よりも inotify-tools の inotifywait というものを使うと便利っぽい。残念ながら現在私はMacですけどね。(brew install wait_on だけで入ってくれる魅力に勝てなかったのよ…)
wait_on は監視するファイルを引数で受け取るのですが、引数が多すぎるとエラーコードを返すわけでもなく処理を終了するため、無限ループになっている今回のコードとはすこぶる相性が悪いです、はい。つまり wait_on がちゃんと仕事しないときでもループは回り続けます(キリッ
あとは引数無しの場合はこのスクリプトを実行したディレクトリ以下(.git/ ディレクトリ以下は除く)のディレクトリを再帰的に wait_on に渡しています。そのため、実行したディレクトリ以下のどんなファイルの変更(git で管理されていないファイルの変更も含む)も読み取ってgit nowします。
つまり何の変更も無い場合でも git now をします。エディタが勝手に作る一時ファイルでも git now します。
とりあえず、git now の前では git add -u が走るようにしているので、インデックスにないファイル(git ls-files で一覧に無いファイル)はコミットされません。スクリプト実行後に追加でファイルをコミットする場合は自分で add する形です。
またディレクトリもスクリプト実行後に生成されたものは、最初の一回だけは監視されていません。二回目以降は監視されます。
…といろいろダメだと言う事を書きなぐってみた。
久々にUNIXのコマンドやらシェルスクリプトやらをいじってたからいろいろ忘れてた。ちょっとしたリハビリにはなったかな…
追記:
kqueueというシステムコールを使うとファイルの変更を監視できるらしいけど、システムコールなので監視対象をファイルディスクリプタで指定になったりするあたり、今回のように管理対象が多いとちょっと不安。。。