Git 6

svnだエラーの出る状態でコミットするなとか言い出す人が多かったな。
エラーの出る状態から作り直して失敗したらどうするんだ。
svnでもブランチとか適切に運用できていればいいんだろうけど。

>>369
gitでもエラーの出る状態で入れないでよ

ローカルで正しく直してからプッシュするというのなら
エラーが出る状態でもいいかな。

エラーが出る出ない以前に
作業途中でコミットするのが納得できんな

単に途中経過を保存したいならstashがあるし
途中経過を他の人に見てもらいたいならMLや掲示板とかの方がいいだろう

>>372
stashはpopという引数があることからもわかるように
スタックという考え方が基礎になってるんだ。

作業途中の割り込み、の割り込み、の割り込み
といった用途で使うもの。

作業途中のコミットは、
いくつかの作業を並行して行っている場合に使う。

Aという作業をやっている途中で、
Bという作業をやってさらに
Cという作業に移ってAという作業に戻る。
と思ったら、Cという作業を進めなくてはならなくて
次はBみたいな。

stashはpullとかmergeする際の本当に一時的な退避にしか使わない
時間が経つとstashしておいた事実を(俺が)忘れてしまう
作業が割り込む場合は作業ブランチ切ってコミットしてる

>>367
それはロックの本質をわかってない

>>372
あとでそのエラーになった修正を使いたくなるかも知れないじゃないか。
それにチケットと関連付ける時にソースもあった方がわかりやすい。
公なとこにpushするなら、その前にまとめればいいだけだし。人のローカルリポジトリに口出しするとか、わけわからんわ。

mercurialがいろいろ縛った理由をちょっと理解できた気がする

> 人のローカルリポジトリに口出しするとか、わけわからんわ。
っ鏡

まあ言ってることが自己矛盾してるわな

作業途中でコミットできるのがgitのいいところじゃないか。
手元でずいぶん変更したけど まだビルド通らない/テスト通らない/バグが直りきってない ときにコミット我慢するの？
途中まで実装したけどやってみると案外うまくいかないな。もう一つの案をで実装してみるか、ってときにその瞬間のコードをコミットしないの？

作業状態の保存(commit)と成果物の公開(push)を分離したところがgitの改善点だろ。
svnと同じタイミング・粒度でしかコミットしないという使い方も否定されないとしても、厳しすぎる制約を自ら課しているんだというのは認識しといた方がいいよ

もう一つの案を実装してみるときはブランチを切る
作業途中ならstashで保存する

これがベストな方法とは言わないし
他人のローカルリポジトリに口出しする気もないが
少なくとも作業途中でコミットする必然性はない

ブランチ切るのにコミットしないんだ。ふーん

svnでもいただろ。「また完成してない」とか言って何週間もコミットしない奴が。
手元に巨大な変更を抱えてて作業コピーの日付バックアップを一生懸命とってるの

testブランチでコード書いた後は
git checkout master
git merge test
git add -A
git commit -m "ちょめちょめ"
git push

この流れで合ってますか？

>>384
Gitでは「まだ完成してない」とか言ってpushしない奴ということになるわけですね

まああれだ。
自由ってのは便利だが、一定のルールで遵守させなければならないと。