- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
149 ：デフォルトの名無しさん[sage]：2015/07/03(金) 08:59:41.32 ID:DfE7bDzR - いやだから、cherry-pickの結果、コンパイル通らなくても構わないのであれば、そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても、意味のある単位で分割されてれば阻害要因にならないよね。
>>143の例のようなモジュール単位でコミットを分ける、というのも意味のある分かりやすい単位だけど、複数のコミットの一部しか適用していない状態だと全体のコンパイルが通らないという弊害がある。
ガイドラインとして、それを許容するか否か、ということが論点のつもりだけど。
また、それを許容しない場合は、rebaseしたときに、手を入れた各コミットの段階ごとにコンパイル確認が必要になる。
全コミットでコンパイル保証をするというのは、その手間を払う価値があるか否か、というのも論点になる。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
152 ：デフォルトの名無しさん[sage]：2015/07/03(金) 10:45:33.74 ID:DfE7bDzR - >>149
>そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても
誤解を招く表現な気がしたので訂正。
>そのコミットを指定してcheckoutしたときにコンパイルが通らないとしても
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
155 ：デフォルトの名無しさん[sage]：2015/07/03(金) 12:43:03.22 ID:DfE7bDzR - >>153
>意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。
>これは阻害要因じゃないのか？
確かにbisect使ったことないけど、コンパイル出来ないと何が困るの？
そのコミットをskipするなり、無視するスクリプトにするなり出来そうだけど。
git bisectのマニュアルにはその例が載ってるよね。
http://www8.atwiki.jp/_pub/git_jp/git-manual-jp/Documentation/git-bisect.html
>rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。
>そんなに手間だろうか？
ごめん、こっちは全然分からない。
bisectは二分探索だと思ってたけど、ある範囲のコミットを全チェックすることも出来るの？
そして実際にそうすることをガイドラインに組み込むべきだと思う？
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
157 ：デフォルトの名無しさん[sage]：2015/07/03(金) 14:34:13.11 ID:DfE7bDzR - >>154
post-commit hookで何をしたいのかな？
コンパイル確認じゃないよね？
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
161 ：デフォルトの名無しさん[sage]：2015/07/03(金) 15:46:36.46 ID:DfE7bDzR - >>159
いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど？
まさか、post-commit hookでコンパイル確認させるつもりじゃないよね？
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
165 ：デフォルトの名無しさん[sage]：2015/07/03(金) 16:28:38.11 ID:DfE7bDzR - >>162
だから、何をやらせようとしてるんだよ。
commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。前提を満たすかどうかのチェックをさせるならまだ分かるけど、それにしたって0.1秒以内に終わる程度の処理しかさせたくないな。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
167 ：デフォルトの名無しさん[sage]：2015/07/03(金) 16:44:05.36 ID:DfE7bDzR - >>164
>結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、
>コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。
そこが、bisectの経験が無くて分からないんだけど、bisectの結果、最後にコンパイル出来てテストも通るコミットと、その次のコンパイル出来てテストに通らないコミット位置が分かるんじゃないの？
その間にあるコミットはコンパイルは出来ないかもしれないけど、分かりやすい単位で分割されているから、バグを特定しやすい気がするんだけど。
>bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ
>した事にすればいい。結果的に全部のコミットがコンパイルされる。
なるほど、こちらはためになった。
全スキップさせれば、全探索になるのか。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
168 ：デフォルトの名無しさん[sage]：2015/07/03(金) 16:51:48.49 ID:DfE7bDzR - >>166
>> commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
>ひょっとして、数分に一回くらいの頻度でコミットしてるのかな？
作業中は数分間隔でコミットするね。
1日に均しても数回だろうけど。
>1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。
1日数回なら、commit hookに任せずに、自分でコマンド叩くよ。
commitの度に自動ビルド、自動テストなんて、こっちの環境じゃとても耐えられない。
ガイドラインの前提には出来ないな。
|