- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
148 ：デフォルトの名無しさん[sage]：2015/07/03(金) 00:27:07.02 ID:9/hHKZ1h - >>147
cherry-pickの結果コンパイルは出来なくても意味のない単位で分割するよりは
必要な修正がまとまっている分、不完全なものになる可能性はずっと低くなる
例えば、Aに前処理とBに本処理がコミットが分かれていて
Bのみを拾った場合、理解不能な挙動をを起こすことになる。
コンパイルエラーになるならまだ良いほうで、
偶然コンパイルが通った場合は余計なデバッグに時間を費やすことになる。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
153 ：デフォルトの名無しさん[sage]：2015/07/03(金) 10:55:08.66 ID:9/hHKZ1h - >>149
意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。
これは阻害要因じゃないのか？
rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。
そんなに手間だろうか？
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
164 ：デフォルトの名無しさん[sage]：2015/07/03(金) 16:21:58.51 ID:9/hHKZ1h - >>155
スキップは例外的にコンパイルエラーが出てしまう場合にも
bisectを継続できるようにするための機能であって、常時使うような方法じゃないよ。
コンパイルエラーでスキップしたコミットがあると、当然中身はテストされないので
正確なエラー発生位置がわからなくなってしまう。
結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、
コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。
bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ
した事にすればいい。結果的に全部のコミットがコンパイルされる。
git bisect run sh -c ‘make; exit 125’
勢いで簡単にできるように書いてしまったが、本来の使い方じゃないね。
|