問題タブ [git-bisect]

私はbisectqtwebkitを開始しましたが、最初の段階でコンパイルしようとすると、次の例外が発生しました。古いqmakeを使用してみましたが、それでも同じ例外が発生します。これは実際にはどういう意味で、どうすれば修正できますか。

実行git bisectすると、各二等分後に次のような出力が生成されます。

で使用されているものと同様に、部分的なコミット名プレフィックスを使用させることはできますgit log --abbrev-commitか？このようなもの：

リポジトリのルート ディレクトリ以外の場所から git-bisect コマンドを実行しようとすると、次のように通知されます。

このコマンドは、作業ツリーの最上位から実行する必要があります。

何故ですか？この要件を持つ他の git コマンドを私は知りませんし、bisect が特別であるべき明確な理由もわかりません。man ページにも、この制限については言及されていません。

それは本当に大したことではありません。私は主に好奇心旺盛です。

私はgitを初めて使用し、「git bisect」を発見しました。新しく作成された単体テスト (事前に存在しなかったもの) を使用してエラーをチェックできる場合、一般的にどのように使用されますか?

単体テストを含むリポジトリがあるとしますが、よくあることですが、それらは完全ではありませんでした。一部のバージョンで機能が動作していないことを発見しましたが、それが以前のバージョンにあったことはわかっています。残念ながら、その機能は単体テストではチェックされていません。私が今やりたいことは次のとおりです。

1. テスト ケースを作成します (もちろん、最初は失敗します)。
2. このテスト ケースを使用して、git bisect を使用してエラーを導入しているコミットを探します。
3. エラーを修正し、修正 (およびテスト ケース) をコミットする

この使用例には 1 つの問題があります。git bisect が古いバージョンをチェックアウトすると、挿入されたばかりのテスト ケースが存在しないため、エラーのチェックに使用できません。テストをコミットせずに、ローカルの変更として保持することができます。しかし、tests ファイルが途中のバージョンで変更されたと想像すると、マージの競合が発生する可能性があります。

じゃあ何をすればいいの？git bisect は一般的にどのように使用されますか?

topic-branch-7 のティップにバグがあることはわかっていますが、master のティップにはバグがないことがわかっています。topic-branch-7 のどこでバグが導入されたかを調べたいと思います。だから私は以下を実行しました：

私を投げているのは、 git bisect good を実行しても何も起こらないということです! コミットを良いものとしてマークし、このコミットと悪いコミットの中間点を見つけて、そのコミットをチェックアウトするべきではありませんか? なぜ何も起こらないのですか？

LogViewerとLogAnalyzerの2つのプロジェクトがあり、どちらも別々のgitリポジトリで開発中であり、LogViewerはLogAnalyzerに依存しています。LogViewerでgitbisectを実行しようとしていますが、新しいコミットをテストするたびに、適切なAPIを備えたLogAnalyserでコミットを見つけてチェックアウトする必要があり、これは煩わしく時間のかかる作業です。これを行うためのより良い方法はありますか？

私は、(この質問の範囲外の理由で) 2 つの git リポジトリに分かれているプロジェクトに取り組んでいます。これは Web プロジェクトであり、共通のライブラリ レイヤー (リポジトリ A に格納) と特定のプロジェクト レイヤー (リポジトリ B に格納) があります。

を使用して、どちらのリポジトリにもある可能性がある場合、どのコミットが特定のバグを導入したかを把握するための効果的な作業方法はありますgit-bisectか? B でa を実行している間、A でのコミットを一定に保つなどのことを試しましたgit-bisectが、B の変更が A に依存していることが多いため、相互作用が複雑すぎます。(これらの変更は私が探しているバグとは関係ありませんが、サイトの読み込みを停止するため、有効なテストを行っています)。

git-bisect2 つの sをリンクして、git bisect goodまたはbad一方のリポジトリで、もう一方のリポジトリで最も近いコミットをチェックアウトする方法はありますか? または、それらを一時的にマージして、何らかの方法で一緒にテストしますか?

範囲を絞るだけでもいいアプローチがあればスタートです。

次のような履歴があります。

もっと学びたいと思ってgit bisectいますが、この歴史に問題があります。私はそれ107ca95が良いことと3830e61悪いことを知っています。を実行するgit bisectと、コミット107ca95..3e667f8が無視されます。43a07b1それがリグレッションを導入したコミットであることはたまたま知っていますが、評価されることはありません。

これが大まかに私がやったことです：

私が何をしても、107ca95..3e667f8テストのためにチェックアウトされることはありません。

これらのコミットをテストするために、バイセクト中に履歴を本質的に「平坦化」できる方法はありますか? インタラクティブrebaseを使用して履歴を平坦化できることはわかっていますが、そうする必要はありません。

ずっと前に導入されたバグがあり、それをテストするのは苦痛です。しかし、バグを引き起こす変更が 1 つの特定のソース コード ファイルで行われたのではないかと強く疑っています。

その 1 つのファイルを変更したコミットのサブセットに対して git bisect を実行できますか?