この問題を解決するのに、簡単で「乱暴な」方法があります。

単に:

最後のリビジョンのきれいなコピーをチェックアウトします。 言い替えると、変更のまったくない第二のプロジェクトを作ります。

新しいツリーでそのつまらないバグを修正しコミットします。 これで、そのつまらないバグ修正を加えたきれいな変更をコミットします。

update か replay コマンドによって、元のツリーを最新に状態にします。 部分的に完了した変更と共に、自分のツリーに対してささいなバグ修正を追加します。

それは動くには動きますが、面倒です。 ちょっとしたバグを潰すためだけに、二つ目のプロジェクトを始めたいと本当に 思いますか?

しばしば、その面倒さは報われることもあります。 たとえば、プロジェクトは、コミット前には必ずなにかのテストを 実行しなくてはならないというような決まりがある場合です。そのような場合、本当に 二つ目のツリーが必要となるでしょう。

別の状況では、その面倒な処理は本当に避けたいことになります。たとえば もしそのささいなバグ修正が、すでに大きな変更を加えてしまったファイルの修正を ともなうような場合です。そのときでも乱暴な方法は一番単純なアプローチではあります (しかしまた、 larch undo ––help と larch redo ––helpを見てください)。

しかし、ときどき許容される、もっと簡単な方法もあります: