ここからどうするかというと、この新しい孤島のtmpに、書き換え以前のmasterのコミットを適用しなおします。–ontoを使います。masterすると(うまくマージが動けば)修正済みのmasterブランチが出来上がってくるはずです。昔の書き換えたいコミットである、oldrootが今度は孤島になりました。過去コミットのAuthor/Comitterを書き換えたい以前適当に使っていたので、設定する名前とメールアドレスも適当でした。マシンごとに違った設定だったり、セットアップしなおすたびに適当に違うメールアドレス入れたり。hoge@gmail.comでもそうすると、誰がコミットしたのか訳がわからなくなってしまって、困ってしまいます。公開するときにはこれを統一したい。overflowに書いてあるのでそのまま受け売りすると、filter-branchを使うと書き換えられるようです。HEADとやって、コミット時にいろいろ書き換えられます。filterのなかに書いてあるのはシェルスクリプトで、sedを使ってファイルを書き換えることもできますし、上記のように環境変数を指定することで、メタデータも書き換えられます。書き換えられるメタデータは以下:GIT_AUTHOR_NAMEGIT_AUTHOR_EMAILGIT_AUTHOR_DATEGIT_COMMITTER_NAMEGIT_COMMITTER_EMAILGIT_COMMITTER_DATE特定のファイルを全部除去したい今度は例えば、画像処理プログラムのサンプルで、著作権的によろしくない画像を使ってた...みたいなケースです。HEADってやれば、ファイルとか全部消せます。examplesにいろいろかいてあるので試してみてねおわりrebaseの話はあんまり見ないので、そちらを重点に、以前やったことがある書き換えについて書いてみました。gitのブランチを詰将棋みたいに書き換えるゲームもあったりするようで、gitのこの辺の機能は強力であると同時に少し難しいですね...。情弱でもSnapでファイルアップロードしたい!HaskellのWebフレームワークSnap、使ってますか!最近ちょっと触ってて、ファイルアップロードがしたいなぁと思ってこんなハンドラを書きました。Snapでは、URLに紐ついたハンドラ(結局モナド)を登録して、特定のURLにアクセスされると、そのハンドラが実行されます。この状態でこんなフォームを書いて送信してみます。</table></form>よくみるとformでのenctype指定がないのですが、最初私は気づきませんでした。ブラウザからアクセス。うーん、acceptできるハンドラがない、ねぇ...。最初、ルーティングがうまくいってないのかな、と思ったのですが、GETで/uploadにアクセスするとちゃんとリダイレクトがかかるので、そこは間違ってないだろう、となると、このPOSTのハンドラが変みたいだ、と目星をつけました。->どれも動かないhandleMultiPartを消してreturnにするとちゃんとレスポンスが表示されるので、どうやらここで例外?が発生してる模様。accepted.」。すべての例外をキャッチできるはずのSomeExceptionを使ってもだめ。例外がキャッチできてないからか、finallyを使っても何も起こりません。tryを使ってもEitherが帰ってこず、処理がスキップされちゃいます。これ、C++で-fno-exceptionした時となんか似てます。例外処理が動いてないのでは?...もっとも、C++の場合はもっと不思議なことが起こったりですが...。Multi-Partのチェックとその失敗処理は例外と直行している中身を見るしかないので読みましょう。まぬあるにて、どうぞ。HaskellのドキュメントシステムHackageでは、rdocみたいにソースが読めます。長いのですが、今回エラー処理が起こされているのはここでした。passpassというので実際に処理を抜けているようですね。このpassのドキュメントはこれ。Exception関係のものがシグネチャにあらわれていないのを見ればわかるように、例外とは一切関係なく処理をスキップ致します。finallyを使っても何も起こせないのは、こういう事だったのですね。debugを有効にしたほうがいいかもしれない環境変数にDEBUG=1を指定するとデバッグモードが有効になります。すると、こんな感じのエラーログがひたすら出力されます。continueこれならコンテント・タイプがおかしいんだな~ってすぐ気づけますね...。開発中はずっとこれをつけといたほうがいいかもしれませんね!ちなみにうまくいくとJustでファイル名が帰ってくるだけの簡単なサンプルプログラムでした。ファイルは扱ってないです...。純粋関数型雑記」を見てたら思い至った話です。「例外、失敗」を処理する方法がたくさんあるのは柔軟で良いと思うのですが、ルールをちゃんとあわせておくか、あるいは別種の「失敗」があることをちゃんと把握しておかないと意図しない挙動になっちゃうのは、悲しいですね...。