14/04/29 16:21:51.52 EYu9TTok
>>258
> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？
トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
263:デフォルトの名無しさん
14/04/29 16:26:11.71 jiz/CQ6q
>>259
いや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
264:デフォルトの名無しさん
14/04/29 16:29:31.48 jiz/CQ6q
>>260
> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？
> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
265:デフォルトの名無しさん
14/04/29 16:30:46.56 +oyspTjV
>>262
ブランチを明示的に分けなくたって、複数人が同じブランチで作業したら実質的にはローカルブランチの分岐が発生しているわけだから、
pushするためにpullするときにマージが発生するでしょ。
266:デフォルトの名無しさん
14/04/29 16:30:55.69 jiz/CQ6q
>>261
> そしてFF only で masterマージ している（かのようなログをした）
> 有名なライブラリ例を上げておく。
> URLﾘﾝｸ(github.com)
そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
267:デフォルトの名無しさん
14/04/29 16:31:51.96 EYu9TTok
>>252
> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。
さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。
履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
268:デフォルトの名無しさん
14/04/29 16:40:59.32 jiz/CQ6q
>>267
> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。
うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
269:デフォルトの名無しさん
14/04/29 16:43:19.24 EYu9TTok
>>266
> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？
トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。
もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。
そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？
と考えていると推測。
俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
270:デフォルトの名無しさん
14/04/29 16:51:05.11 jiz/CQ6q
>>269
> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、
ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？
俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
271:デフォルトの名無しさん
14/04/29 16:53:09.53 EYu9TTok
>>270
説明してるじゃねーか。
ライブラリの作者じゃないんだから
作者の本当の考えはわからん。
それは当たり前。
それとは別に推測で
ちゃんと説明してる。
272:デフォルトの名無しさん
14/04/29 16:59:55.32 EYu9TTok
>>270
> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？
コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。
（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。
大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
273:デフォルトの名無しさん
14/04/29 17:07:40.73 EYu9TTok
ちなみに俺が反論している所を明確にしておくと、
「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。
トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。
履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。
rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。
（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
274:デフォルトの名無しさん
14/04/29 17:14:28.12 jobIXRFq
トピックブランチのコミットが2個以上なら
マージはどうあれno-ffでやるべきだろ。
ffでマージしちゃったら、
あとでそれらコミットがなんのトピックに属していたのか
わかりにくくなるんだから。
そういうケースまで一直線のほうがいいとか言うのはアホ。相手にするだけ無駄。
275:デフォルトの名無しさん
14/04/29 17:18:53.63 EYu9TTok
連投するが、俺がいいたいのは
・masterへのマージするときはno-ffをつけろ。（念を押すがmasterへのマージの話）
・コンフリクトが起きるようなmasterへのマージは禁止。
・rebaseはしたほうがベター。なぜベターなのかというと履歴が一直線になって見やすいから。
ということ
この結果、no-ffでmasterへマージする前に「rebaseするのは一般的なオペレーション」になる。
そしてrebaseしていなくても、コンフリクトが起きなければmasterへno-ffマージしてよいので
そうするとマージ前のrebaseの有無は関係なくて単に「masterへはno-ffマージしろ」って話になる。
276:デフォルトの名無しさん
14/04/29 18:11:38.86 jiz/CQ6q
>>273
コミットグラフを書けるかちょっと試し書き。ずれてたらすまん。
お前の主張は
A-B-C
/ \
X-------M-M
\ /
D--E--F
こういう変更は DEF をrebaseして
A-B-C
/ \
X-------M---------M
\ /
D'-E'-F'
こうすべき、ってことでいいかい？
俺的にはどちらもfirst-parentで
\
X-M-M
/
に要約可能だからどっちでもいいよ。
# ただ自分でやる場合はコンフリクトしない限り前者のほうがrebaseしなくていいから楽だけと思うけどね。
# もちろんDEFのマージ時にコンフリクトしたらrebaseすることもある。DEF開発者によるmergeも可。
277:デフォルトの名無しさん
14/04/29 18:12:17.95 jiz/CQ6q
疑問視してるのは
X-A-B-C-D'-E'-F'
にすべきという主張だ。
これはA-B-CとD-E-Fが本来別の目的を目指して重ねたコミットだという情報が失われてしまうから
たとえ一直線でもわかりにくいと俺は主張しているんだよ。
トピックが2個程度ならどっちでも良さそうだが、トピックが数十の場合を想像してくれ
X-M-M-M-.....M-M
という数十個の要約を見る(必要に応じてトピック内のABC等を確認する)のと
X-A-B-C......(区切りもなく、めちゃくちゃたくさんのコミット)....x-y-z
を見るのと、どっちがわかりやすいの？ってこと。
278:デフォルトの名無しさん
14/04/29 18:15:08.80 jiz/CQ6q
ブラウザによっては結構ずれるな。わかんなきゃ無視してくれ。
279:デフォルトの名無しさん
14/04/29 18:24:55.80 VGBInRA4
2.0からデフォルトでFF onlyになるのは知ってるよね君たち
どうしてこうなったのかもちろん議論されてるのも知ってるよね
280:デフォルトの名無しさん
14/04/29 18:25:46.52 ABe1tyQZ
これもうわかんねえな(バグったときの修正範囲が)
281:デフォルトの名無しさん
14/04/29 18:30:04.67 qq5sN0hH
>履歴は一直線になっていたほうがわかりやすい。これは事実。
一見わかりやすい気がするっていうのと、意味的にわかりやすいというのは別だと思うのだがどうだろう
svn のように時系列にコミットが一直線に並んでるのはわかりやすいか？
rebase → ff マージでトピック内の全コミットをフラットにしたのがわかりやすいか？
rebase → squash マージだと master のコミットグラフは一見綺麗になるかもしれんが実態はちょっとアレだし
そしてfirst-parentオプションつければたとえ一直線でなくとも意味的に見やすいログが手に入るんだろう
282:デフォルトの名無しさん
14/04/29 18:44:21.18 jiz/CQ6q
>>279
pull.ff 設定が可能になったのは確かだし、単に上流を追従するだけでその上で作業しないリポジトリなら
ff-onlyのほうが嬉しいのは確かだが、今議論してる内容とは前提が全然違うぞ。
# rc1だがmergeもpullもデフォルトでFF onlyな動作じゃないのを確認しちまったじゃねーか。
283:デフォルトの名無しさん
14/04/29 18:45:53.07 jiz/CQ6q
>>281
そうそう。
ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
284:デフォルトの名無しさん
14/04/29 19:02:08.02 ABe1tyQZ
ベースブランチの状態が多いイコール検証箇所も多くなって面倒だからそうならないようコミットも最小限にしたほうがいいんじゃないの
285:デフォルトの名無しさん
14/04/29 19:47:52.24 6KBRCzBr
>>223
というわけで、実験してみた。
ブランチ削除しても履歴はのこるんですね。
そのツリーがごっそりなるものだと思ってた。
マージにしても、前やったときは、強制的に変なコミットログ追加されて気色わるかったきがしたけど、今やると普通だな。
僕含めまわりもまだ不慣れなので、ＦＦ縛りは、外せないけどマージするだけなら問題なさそう。
286:デフォルトの名無しさん
14/04/29 19:56:50.37 EYu9TTok
> ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
ね？ 一直線は見やすいでしょ？
常にに--first-parentするわけじゃないので、
しなくても一直線になったほうが嬉しいよ。
287:デフォルトの名無しさん
14/04/29 19:58:40.00 jiz/CQ6q
>>285
報告ありがとう。
今後もGitに慣れるにしたがって、見え方も変わってくるかもしれないな。
周りも不慣れということで大変だと思うが、お前のプロジェクトのベストプラクティス確立にむけて頑張ってくれ。
グッドラック。
288:デフォルトの名無しさん
14/04/29 20:21:45.22 jobIXRFq
一直線バカは救いようのないバカだな
289:デフォルトの名無しさん
14/04/29 23:30:04.09 +oyspTjV
「履歴が一直線になってわかりやすい！」かどうかって、もはやコミットの順序というものにどういう意味があるかどうかという意味論なのだから、
ケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
290:デフォルトの名無しさん
14/04/30 00:35:08.42 UGHSixxv
一直線が良いケースが挙げられてないけどな
291:デフォルトの名無しさん
14/04/30 01:11:54.22 pWom3qZR
一直線： 見えを貼りたいだけのバカ。俺はまっすぐ順調に開発をしてきたというアピールがしたい
292:デフォルトの名無しさん
14/04/30 01:29:11.37 Gbwo+6jG
東大一直線
293:デフォルトの名無しさん
14/04/30 05:04:21.07 mdKtpEfX
意味不明なエラーでpush不可能になった
remote: FATAL: WM refs/heads/*** **** **** DENIED by fallthru
remote: error: hook declined to update refs/heads/***
git reset --hard origin/upstream_worktree
して差分再適用してやり直したら通った
こんな意味不明なことが多発するのがgit
現実的には使い物にならないね
294:デフォルトの名無しさん
14/04/30 08:30:44.87 1vNQkGgC
hook declined
ってかいてあんじゃん
295:デフォルトの名無しさん
14/04/30 11:02:23.25 4gXDKzV2
書き込み時刻を見ろ 察してやれ
296:デフォルトの名無しさん
14/04/30 14:42:09.85 mdKtpEfX
dis発言に対してはただ叩くだけ
それも論理的に叩けないから人格攻撃に走るしかない
情けない奴らだよな
297:デフォルトの名無しさん
14/04/30 14:48:31.80 mdKtpEfX
別リポジトリで他人による大量の更新があって
半端にマージした挙げ句途中でこけて
半端にステージングした状態になり
結局
git reset --hard origin/upstream_worktree
するしかなくなった
ここまで致命的に腐ってると使い物になるならない以前の次元だね
298:デフォルトの名無しさん
14/04/30 14:55:49.07 nKoANYQ+
またいつものコンフリクト恐怖症の人か
299:デフォルトの名無しさん
14/04/30 18:26:55.40 mdKtpEfX
コンフリクト解消で済めばいいんだが腐ってるから済まないんだよね
300:デフォルトの名無しさん
14/04/30 18:51:13.84 h9gMUOtr
なるほど、コンフリクトの解消の仕方が分からないから
コンフリクト恐怖症になってしまったのか
301:デフォルトの名無しさん
14/04/30 18:51:51.42 rHgIYikH
Aリポジトリでもらったpull requestを
Bリポジトリに反映する方法を教えてください
302:デフォルトの名無しさん
14/04/30 18:59:19.90 1L5gAVQy
ところで、大声でジットと呼ぶ人がいて困ってるんだ
ディスクトップパソコンみたいな
職場がSubversion教に汚染されてるので仕方ないな
303:デフォルトの名無しさん
14/04/30 19:12:36.93 ZY5HChQC
じっと我慢汁
304:デフォルトの名無しさん
14/04/30 19:50:56.80 fWhizGrM
レーダーデスクカラオケ
305:デフォルトの名無しさん
14/04/30 19:56:34.41 EonfyA0Y
ギットギトにしてやんよ
306:デフォルトの名無しさん
14/04/30 20:25:07.89 WuyiDL68
>>297
> 半端にマージした挙げ句途中でこけて
(コンフリクトしたときのデフォルトの動作だ・・・)
> 半端にステージングした状態になり
(コンフリクトしたときのデフォルトの動作だ・・・)
> 結局
> git reset --hard origin/upstream_worktree
> するしかなくなった
(コンフリクト解消できなかったなら git merge --abort すればよかったんじゃ・・・)
307:デフォルトの名無しさん
14/04/30 21:19:26.86 livyiFPX
>>297
> git reset --hard origin/upstream_worktree
わろたｗｗｗｗ
え？ あんた自分の作業けしちゃったの？ｗｗｗ
馬鹿だなぁ。
gitはsubversionと違ってmergeやrebaseの途中で
コンフリクト起きてごちゃごちゃなっても、
merge/rebase作業をキャンセルして簡単に戻せるのにｗｗｗ
情けだ、ヒントをあげよう。
mergeしてるってことはコミットしてるってこと。
そのコミットIDはgit reflogすればわかるので
あとはそのコミットIDをチェックアウトすれば前の状態に戻せる。
gitはコミットしたものが消えることはない。
gitって安全だよねー
308:デフォルトの名無しさん
14/04/30 21:28:01.99 upmIhAH5
>>217
プロジェクト名に言語が入ってないとなんの言語で作ってるのかわからないじゃん
言語を変えたらリポジトリ名を変更すればいいじゃん
309:デフォルトの名無しさん
14/04/30 21:58:49.74 Y0BKcERE
>>308
悪いことは言わないから足を洗え。
310:デフォルトの名無しさん
14/04/30 22:12:33.53 livyiFPX
そういやgithubってプロジェクトで使用している言語がわかるようになったよね。
gitだと、カラフルなバーをクリックすると以下のように表示される。
C 45.5% Shell 34.6% Perl 9.6% JavaScript 3.4% Python 2.9% Tcl 2.6% Other 1.4%
>>308
で、このようにリポジトリにプロジェクト名入れなくても
githubならわかるし、gitのように複数言語使ってる時どうすんの？
そんなことも考えれずに、言語名にこだわるなら、
センス無いなとしか言えないなｗ
311:デフォルトの名無しさん
14/04/30 22:41:41.21 rUdHCEgh
githubだけの視野で語られても
312:デフォルトの名無しさん
14/04/30 22:42:55.54 livyiFPX
github以外のプロジェクトでも
複数言語でアプリ作るのは一般的だけど？ｗ
313:デフォルトの名無しさん
14/04/30 23:26:12.17 mdKtpEfX
307は本当に馬鹿なんだなぁ
管理されてないファイルがreset --hardの対象にならないことは以前に確認済みだから関係ないし
コミットしたものはすぐに権限持ちに差分送ってるし
コンフリクトは元々未来分の作業は既に入っててそこからコメント消す程度
俺が泣かなくて残念だったな
314:デフォルトの名無しさん
14/04/30 23:51:07.78 1vNQkGgC
結局gitのおかげで無事でした
めでたしめでたし
315:デフォルトの名無しさん
14/05/01 00:28:44.24 WukXr8jq
＞＞３１２
プロジェクトを1つのディレクトリに詰め込むタイプですか？
316:デフォルトの名無しさん
14/05/01 09:28:45.91 PzUwUPDQ
>>313
意味がわからないなあ
コミットしたものを権限持ちに既に送ってあるとしたら、
お前が上流からマージしようとしたブランチは一体何なの？
お前がコミットしたものを含んでいないブランチ？
317:デフォルトの名無しさん
14/05/01 11:07:25.45 PVO7jj2i
>>315
なんでそんな発想が出てくるんだ？ (w
318:デフォルトの名無しさん
14/05/01 11:24:48.42 /DVUm5po
おれはさ
php/wiki
php/cms
php/mailform
っていうふうに管理してるの
他の言語で同じ物を作ることもあるから
ruby/wiki
みたいに言語をネームスペースにすると管理が楽なんだよ
319:デフォルトの名無しさん
14/05/01 17:12:30.25 PzUwUPDQ
>>318
それとGitと何の関係があるんだ？
320:デフォルトの名無しさん
14/05/01 17:20:29.51 U31MyfYF
Gitはソースコードを管理するわけだからプロジェクトと関係あるだろ
C:/appData/User/toyohiko/マイドキュメント/mycode/php/wiki
これを外部のリポジトリ管理サービスに突っ込むときのリポジトリ名はphp-wiki
321:デフォルトの名無しさん
14/05/01 17:24:28.79 n23f7Uie
名前付けのポリシーとか別に好きにすればいいと思う。
322:デフォルトの名無しさん
14/05/01 17:44:02.84 PzUwUPDQ
>>320
そんなもん上流のリポジトリ管理方針次第だ
例えば俺はandroidのapp01プロジェクトを
ssh://remotehost/repo/android/app01.git とかに格納してる
323:デフォルトの名無しさん
14/05/01 17:52:02.03 U31MyfYF
>>310
複数言語使っているときは
C:/appData/User/toyohiko/マイドキュメント/mycode/other/wiki
というようにして言語名のフォルダにいれず名前空間に言語名を付けない
324:デフォルトの名無しさん
14/05/01 18:01:12.45 n23f7Uie
もう自由にタグ付けできる自分用プロジェクト管理ツール使っちゃえよ。
325:デフォルトの名無しさん
14/05/01 18:13:02.15 ZgnY/tZG
>>318
コードネームつければいい。
phpは犬の種類、rubyは猫の種類とか原則を持たせても良い。
326:デフォルトの名無しさん
14/05/01 19:05:29.45 PzUwUPDQ
>>323
githubがリポジトリを「URLﾘﾝｸ(github.com)ユーザー名/リポジトリ名」で管理してるのは
githubの管理方針であって、gitとは直接関係無いということが理解できた？トヨヒコくん
327:デフォルトの名無しさん
14/05/01 19:26:56.62 3NSQaEE2
だからさGitHubだけで語るな
328:デフォルトの名無しさん
14/05/01 22:47:07.56 dcOXu/fE
確かにSubversion使ってたときは一つのリポジトリに色々入れてたけど(そしてSubversionを適当に使う限りではそれで事足りてた)、
Gitは部分チェックアウトも出来ないしコミットもブランチも困ることだらけだからプロジェクトごとにリポジトリ分けるのが当然だよな。
自分もGit初心者の頃はSubversionと比較しちゃって部分チェックアウトが出来ないのが不便だのsvn:externalsと完璧に同等のものがないのが困るだの言ってたけど、
そのときGitユーザーから「Subversionとは思想が違うから比較するのは意味が無い」的なことを言われたけど、今はまさにそのとおりだと思うよ。
とりあえずSubversionでややこしい開発はしたくないね、もう。
329:デフォルトの名無しさん
14/05/02 03:41:26.83 ZGvM0amq
>>316 pullするだけでその状態になることすらわからないとかお前本当に馬鹿だな
330:デフォルトの名無しさん
14/05/02 03:48:34.89 PU3lP69m
>>326
はあ？リポジトリ名の話なのに
＞「URLﾘﾝｸ(github.com)ユーザー名/リポジトリ名」
ってなんだよ話そらしてんじゃねえよ
331:デフォルトの名無しさん
14/05/02 06:22:29.35 KJDTZacL
自分の管理下にあるリポジトリなら好きに名前付けりゃいいじゃん
332:デフォルトの名無しさん
14/05/02 06:35:41.08 Ujs4NpLL
>>330
とよひこ君はまだわからないのか
githubじゃなければ、リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
333:デフォルトの名無しさん
14/05/02 06:37:10.90 Ujs4NpLL
>>329
pullするだけですべてうまく行くと思ってるのは幻想だ
ちゃんと勉強したほうがいいな
334:デフォルトの名無しさん
14/05/02 08:09:07.29 ZGvM0amq
わざわざvcsの勉強なくて無価値なことはしたくもないね
335:デフォルトの名無しさん
14/05/02 08:29:32.57 Ujs4NpLL
Gitに関しては勉強する価値があった
正直まともなVCS使わないのは、高機能エディタやIDEも使わずメモ帳で開発するようなもんだわ
336:デフォルトの名無しさん
14/05/02 11:30:23.12 W9jDDFpi
パスワードを含んだファイルがあるんですけど
このファイル内のパスワードを削除して雛形だけの状態にしてからプッシュしてます
一度プッシュしたらほとんど修正はしないファイルなんですがこういう場合ってどうするものですか？
337:デフォルトの名無しさん
14/05/02 13:03:04.92 pbdRog+k
>>336
$ touch password.txt; git add password.txt; git commit
$ git update-index --skip-worktree password.txt
$ echo -n 'himitsu' > password.txt; git status
On branch master
nothing to commit, working directory clean
とか？
338:デフォルトの名無しさん
14/05/02 13:06:17.10 Pfd+HO5D
>>332
> リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
別に、/ スラッシュを使わなくても
php\wiki や ruby\wik でもいいだろう？
php_wiki や ruby_wik でもいいだろう？
339:デフォルトの名無しさん
14/05/02 13:17:21.62 Oia8PEO/
>>336
aaa.confってファイル名だとしたら
.gitignoreにaaa.confを登録してaaa.conf.sampleみたいなファイル名で
コミットしておくのが多いんでないかな
340:デフォルトの名無しさん
14/05/02 14:47:13.55 Ujs4NpLL
>>338
話の流れを読めないアホなのか？>>216が話のはじまりだ
別に本人が / 以外でいいのならそれでいいぞ
ただし、\ で区切るのは勘弁してくれ
341:デフォルトの名無しさん
14/05/02 15:06:33.45 WqSAbr7K
User/repository.gitが
User/php/oreore.gitじゃなくてGItHubが/を-に変換してUser/php-oreore.gitになる
bitbucketは名前を強制的に変換はしないがurlのほうは変換される
余計な機能
342:デフォルトの名無しさん
14/05/02 17:26:31.17 BNaPh7J8
% git clone URLﾘﾝｸ(...) php/oreore.git
すればいいだけじゃねーの。
手元で php ディレクトリが存在してるかどうかに関わらず
Gitは指定したパスにクローンしてくれるよ。
わざわざ指定するのがイヤなら
そういうcloneをするようなスクリプトかぶせてもいいし。
343:デフォルトの名無しさん
14/05/02 17:34:19.17 XSE+HkNu
C:￥testからD:￥testに移動したいんですけど
ファイラーで移動したらgitできなくなりました
.gitの中でどのファイルを開いてパスを書き換えたらいいですか？
344:デフォルトの名無しさん
14/05/02 17:44:12.24 BNaPh7J8
>>343
わからん。ありそうなのは .git/config だが、
適切に答えるには情報が不十分かつ不正確。
345:デフォルトの名無しさん
14/05/02 17:53:43.03 XSE+HkNu
C:￥testでgit initして適当にファイルを作ってコミットして
C:￥testをコピーしてD:￥testにペーストしたんです
D:￥testのなかでgit logしたらログが表示されません
346:デフォルトの名無しさん
14/05/02 18:06:55.59 +HIQMOvh
全く再現しねえな
347:デフォルトの名無しさん
14/05/02 18:07:33.93 XSE+HkNu
eeeeeeeeeeee
348:デフォルトの名無しさん
14/05/02 18:14:47.14 +HIQMOvh
GitBushから
cd /c/temp
mkdir git
cd git
mkdir test1
cd test1
git init
vim README
git add .
git commit -m "initial commit"
エクスプローラで
Cドライブ(C:\Temp\Git\Test1)を右クリックメニューでコピー
Dドライブ(D:\Temp\Git)にて右クリックメニューから貼り付け
GitBushから
cd /d/temp/git/test1
(ちゃんとmasterって表示になった)
git log
(ちゃんとinitial commitのコミットが表示された)
まったく再現しない
エクスプローラ以外のファイラーは知らんが、隠しファイルや隠しフォルダは移動しない設定になってんじゃないの
349:デフォルトの名無しさん
14/05/02 18:23:12.12 3JApfdBs
おかしいな・・・またあとできます
350:デフォルトの名無しさん
14/05/02 20:15:24.71 dlumt8FZ
Gitのこともほとんど具体的な操作方とか知らないままなんだけど、GitHub実践入門を買った
ので、Git操作のお勉強と同時にGithubも使いだした。
351:デフォルトの名無しさん
14/05/02 20:18:51.30 6MkiwdiC
rmした後に全く関係ないファイルをaddするとrmしたファイルのrename扱いになるんですが
単に新規ステージングしたファイル扱いにできますか？
直後にrmしたファイルではなく、始めにrmしたファイルのrenameになっていたり
動作がわけわららんです
352:デフォルトの名無しさん
14/05/02 20:48:37.15 YmhbMTXU
>>337 横レス
設定ファイルとか便利そうだな。覚えておこう。
353:デフォルトの名無しさん
14/05/02 20:49:12.42 6MkiwdiC
どうやら中身が同じファイルは勝手にrename扱いにしてくれるようですね
空ファイルでトレーニングしていたので混乱してしまいました
354:デフォルトの名無しさん
14/05/02 20:59:01.62 6ajnVdK2
>>351
gitのデータ構造としては、ファイルの移動や改名とかは管理してなくて、
表示の時にヒューリスティックに判断してrenameとか出してるだけだから、
気にする必要ないよ。
355:デフォルトの名無しさん
14/05/02 21:02:26.52 6MkiwdiC
>>354
ありがとうございます
そういうものだと、気にしないようにします
356:デフォルトの名無しさん
14/05/02 21:42:27.82 x3xYwsX7
gitはファイルではなくコンテンツを管理していると言われる所以だね。
357:デフォルトの名無しさん
14/05/02 22:17:35.97 Xf1Tcq77
gitでhookファイルを変更した場合
これをGitHubにプッシュした阿戸に
ローカルのファイルとリポジトリを削除してからクローンしたらhookファイルの内容がないんですが何故ですか？
358:デフォルトの名無しさん
14/05/02 23:58:46.02 ojQzvTVb
こんなGit入門の本を買った。
URLﾘﾝｸ(2ch-dc.net)
359:デフォルトの名無しさん
14/05/03 00:29:50.84 9lt90aGA
喜ぶべきか悼むべきか・・・
360:デフォルトの名無しさん
14/05/03 01:42:57.16 fa3rSR83
>>358
それってどう？
361:デフォルトの名無しさん
14/05/03 02:05:49.12 Z2xjVVlJ
>>357
フックは版管理されてないから。configも同様。
フックをシェアしたいならワーキングディレクトリにフックを置いて、Makefileなりsetupスクリプトからインストールできるようにする。
クローンしただけで勝手にスクリプトに走られたら困る。
362:デフォルトの名無しさん
14/05/03 02:07:15.00 vyhhlfA3
>>360
文章読むだけならGithubで公開されてる
363:デフォルトの名無しさん
14/05/03 02:11:26.95 Z2xjVVlJ
>>353
rmしたファイルのindexに注意。git rm。
git mvはgit addとgit rmを同時にやってくれる。
364:デフォルトの名無しさん
14/05/03 07:45:11.01 n1PIULKZ
>>353
中身が似てるファイルね
rename扱いにしてるのはログ表示の時だから、まあ気にしなくていいには変わらない
コピペ検出機能だとでも思っておけ
365:デフォルトの名無しさん
14/05/03 13:12:50.33 EAqxmtFF
リモートにtagをpushした後、リモートに存在するtagを確認するにはどうすればよいのでしょうか
ローカルリポジトリのtagなら git tag, リモートのブランチなら git branch -r ですが、
リモートのtagを表示するコマンドが見つかりません
366:デフォルトの名無しさん
14/05/03 14:26:01.92 H1NY/7i6
git ls-remote リモート名
367:デフォルトの名無しさん
14/05/03 14:26:42.30 oP8j+OVm
>>365
これでリポジトリを直接指定して確認できるけど、
git ls-remote --tags リポジトリのURL
もっといい方法があるかも？
368:デフォルトの名無しさん
14/05/03 14:47:09.37 EAqxmtFF
>>366-367
感謝です！ありがとうございました！
369:デフォルトの名無しさん
14/05/04 11:33:46.82 bQKl4dNQ
リモートリポジトリからPullした直後で一切変更を加えていないにも関わらず
git statusでいくつかのファイルで差分が検出されてしまう現象にが起きています
差分が検出されているファイルのdiffを見るとソースコード全体が入れ替えられたような表示になります
しかし、該当ファイルをgit addしてから再度git diffすると変更点なしと表示されます
現象が起きるファイルは.cpp、.cs等複数の拡張子で
その拡張子のファイルすべてで起きる訳ではなく、頻繁に更新されるファイルで起きているように見えました
この現象についてWeb検索したのですが、該当しそうな情報は得られませんでした
githubのクライアントとVisualStudio2013のgit機能を併用していることに
原因がありそうな気がしているのでそのあたり調査する予定ですが
見直すべき設定等、何かヒントを頂けたら嬉しいです
370:デフォルトの名無しさん
14/05/04 11:50:13.22 IxrX60Uq
>>369
改行コードだな
371:デフォルトの名無しさん
14/05/04 18:11:29.06 Efc5dGc7
git config core.filemode false
git config core.symlinks false
372:デフォルトの名無しさん
14/05/05 12:36:20.36 qzGHizbC
pullは1箇所から取得してpushは複数にする方法を教えてください
AitHubのみpullして
pushはAitHub,BitHub,CitHubの3箇所に送信してバックアップがしたいんです
373:デフォルトの名無しさん
14/05/05 13:48:29.73 bcw2AmGJ
>>372
git remote add知ってる?
374:デフォルトの名無しさん
14/05/05 13:50:28.20 HNW3XBXV
それ知ってますけど1つのとこしかpushできませんよね
375:デフォルトの名無しさん
14/05/05 14:07:54.45 NnoKU6B2
一つの所ってなんですか？ originですか？
なんでいちいち名前を指定すると思いますか？
一つだけなら名前は必要ないはずですよね？
376:デフォルトの名無しさん
14/05/05 14:08:40.84 NnoKU6B2
なんでremote addだと思いますか？
一つだけならremote setでいいはずですよね？
あとは自分で考えてください。
377:デフォルトの名無しさん
14/05/05 18:39:57.72 G1VleuAd
git push {A,B,C}itHub branch
378:デフォルトの名無しさん
14/05/06 11:11:21.75 wWugdkdR
>>369
autocrlfくさい
379:369
14/05/06 15:12:16.47 5E8fiGLl
>>370,371,378
ありがとうございます。
いただいた助言を参考に試行錯誤して、とりあえず以下の操作をしたら
現象が落ち着きました。
・core.autocrlfをtrueからfalseに(Windowsでしか開発しないので)
・core.whitespaceを明示(space-before-tab,trailing-space)
・該当ファイルをVisualStudioの「ドキュメントのフォーマット」を使用して整形
もしかしたらwhitespace周りが原因だったのかもしれません。
どうもありがとうございました。
380:デフォルトの名無しさん
14/05/06 16:27:04.50 dFD2Q7zD
masterブランチの内容をtestブランチに移動して
masterブランチ内のファイルの内容を空の状態にする方法を教えてください
381:デフォルトの名無しさん
14/05/06 18:22:58.02 ms/T2S5F
ファイルの内容を空の状態にする？ファイルのサイズを0バイトにするってこと？
382:デフォルトの名無しさん
14/05/06 18:53:05.44 2kojW0Cn
あるブランチでコミットした内容をmasterに反映させる時rebaseを使えっていうのをここで習ったんですが
具体的にどうやるのか教えてください
git init
touch a
git add a
git commit -m "INITIAL COMMIT"
git checkout -b kaihatu1"
echo "1" > a
git add a
git commit -m "1を追加"
echo "1" > a
git add a
git commit -m "数字を2に変更" ←いまここ
この後から何をしたらいいのか教えてください
383:デフォルトの名無しさん
14/05/06 18:59:41.16 WvF/ZXc8
絵に描いたような教えてクン
384:デフォルトの名無しさん
14/05/06 19:03:35.48 Fr+PW76D
あるブランチでコミットした内容をmasterに反映させる時に使うのはmerge
ブランチには複数のコミットが含まれている。という前提とする。
masterにマージする時のやり方
1. squashして一つのコミットにしてマージ
2. squashせず、マージコミットを作ってマージ（no fast foward）
3. squashせず、マージコミットもつくらずマージ（fast forward）
ブランチは作業履歴とか入っていてコミットが汚いことがあるので
mergeする前にブランチを綺麗にしておくと良い。
ただし1ならコミットは一つになるからrebaseする必要はない。
2. もしくは 3の時、マージされたコミットを綺麗にしておきたいならrebaseする。
小さなバグ修正とか、タイポの修正とかそんなのが残ってても気にしないならrebase不要。
ただし、rebaseせずにfast fowardでmasterにマージすると
revertしづらくて死ぬだろう。コミットが綺麗なら3でも良いが、
2にしておくと、ブランチ単位でrevertできるから楽。
385:デフォルトの名無しさん
14/05/11 13:29:58.96 DrfDcIuJ
1.9.3 がリリースされたね
386:デフォルトの名無しさん
14/05/11 16:13:44.39 8Qasa1hM
>>385
それが・・・どうかしたの？
387:デフォルトの名無しさん
14/05/11 16:14:30.91 M5uHChWE
今回のはつまらんリリースだ
388:デフォルトの名無しさん
14/05/11 17:39:48.22 qkdWQCFA
まだ１．９つかってるの？もうこっちは２．０使ってるよ
389:デフォルトの名無しさん
14/05/11 19:24:38.83 04FzsR6r
俺のはいまだに1.7ですが
390:デフォルトの名無しさん
14/05/11 21:21:49.14 wZvRNfhO
カレントを追いかけているから俺も常に最新・・・
アップデートきてたから1.9.3に今した
391:デフォルトの名無しさん
14/05/11 21:23:17.01 pXskIuQ6
1.8 位から、処理速度が速くなったと思う
392:デフォルトの名無しさん
14/05/12 00:23:32.35 fWwUyCwI
俺初めて使ったとき、まずルートでinitしていつまでも延々待ちになってしまって
壊れているかと思った。
393:デフォルトの名無しさん
14/05/12 12:14:12.48 bllVZHXA
>>390
カレントってなに？gitからクローンすると2.0になるけど？
394:デフォルトの名無しさん
14/05/12 13:44:49.20 1rzT8Re4
>>393
>カレントってなに？gitからクローンすると2.0になるけど？
「現時点で GitHub から Git のリポジトリのクローンを取得してビルドしてインストールすると 2.0 になる」という意味？
現時点で 2.0 は正式版ではなくて RC 版だよ。
URLﾘﾝｸ(github.com)
現時点の最新の 2.0 は 2日前にリリースされた v2.0.0-rc3。
現時点の最新の正式版は 2 日前にリリースされた v1.9.3。
395:デフォルトの名無しさん
14/05/12 16:08:54.91 VMOJUad9
バグ修正が中心のリリースとなる「Git 1.9.3」が公開される
URLﾘﾝｸ(sourceforge.jp)
396:デフォルトの名無しさん
14/05/13 00:02:25.45 cgdWIPbr
>>394
カレントって普通
> 現時点の最新の 2.0 は 2日前にリリースされた v2.0.0-rc3。
を指すんじゃね？
397:デフォルトの名無しさん
14/05/13 00:23:30.33 Kbu/OO7P
カレントって普通は安定板stableの最新版じゃないの
テスト要素のあるrcやβは含まないんじゃないの
398:デフォルトの名無しさん
14/05/13 00:36:15.98 A9K77IIM
普通は安定版だよ
399:デフォルトの名無しさん
14/05/13 00:47:21.79 V9w/ceW7
currentというとバージョン管理システムから持ってきた
開発版のソースを指すケースもあるな
*BSD方面とか
400:デフォルトの名無しさん
14/05/13 01:02:23.02 TNqok+m1
2.0を使ってるひとは、2.0がrc版だって認識して使ってるの？
401:デフォルトの名無しさん
14/05/13 01:09:14.75 8hwDbhT0
RCというのはリリース候補。ベータ版よりも
完成度が高い、リリース版レベルのもののことだよ
402:デフォルトの名無しさん
14/05/13 01:09:32.07 Kbu/OO7P
そりゃそうだろ
ソースからビルドするならタグから引っ張ってくるだろうし
403:デフォルトの名無しさん
14/05/13 01:11:36.76 Kbu/OO7P
>>401
v2.0.0はrcが1、2、3と出てるんですがそれは
404:デフォルトの名無しさん
14/05/13 01:19:56.17 aq/kP6dx
>>403
完成度もせいぜいベータよりはマシ、ってレベルで
gitのリリース版レベルなんてのは所詮その程度だ
ってことを>>401は言ってる。
405:デフォルトの名無しさん
14/05/13 01:21:40.67 TNqok+m1
2.0で付加される新機能を早く使いたいとかGitのバグ取りに協力したいっていうなら理解できるんだけど、それ以外に2.0rcをあえて使う理由ってあるの？
406:デフォルトの名無しさん
14/05/13 05:43:56.92 Tx8Pcw2g
自分が何かgitに関連するモノを作って自分以外の人に提供してるなら
最低でもRCの段階で問題無い事を確認しておきたいな
407:デフォルトの名無しさん
14/05/13 12:15:49.81 KvmMEOaQ
>>406
それは理解できる
でもこのスレの >>388 とか >>393 ってそういう感じじゃないんだよね
GitHubからクローン取得してビルドしたら2.0で、2.0がrcであることも知らないで使っている、そして2.0未満のバージョンのユーザを馬鹿にしている
こんな風に思えてしまう
408:デフォルトの名無しさん
14/05/13 12:57:27.93 0j07nOJV
データを蓄積するツールとして使ってるから安定版。俺はまだ1.7使ってるし。
409:デフォルトの名無しさん
14/05/13 13:06:38.35 vRP8IXzs
>>407
身の回りにいるならともかく、ネットの向こうにいる他人なんてほっとけよ。
あと、>>388 でバカにされたとか思うようなら、このての掲示板見ない方がいいと思うぞ。
410:デフォルトの名無しさん
14/05/13 13:14:13.76 +cSIqVHp
gitでバージョン番号管理って、みんなどうやってる？
411:デフォルトの名無しさん
14/05/13 18:24:36.93 A9K77IIM
vistaでgui使ってコミットするファイルの選択してたら固まりまくったんだけどなんなん
1.8.4で起きて1.9.2に更新しても再発した
もろもろ込みの15mくらいのexe
Git-1.8.4-preview20130916 → Git-1.9.2-preview20140411
412:デフォルトの名無しさん
14/05/13 18:42:33.12 KvmMEOaQ
>>409
了解
413:デフォルトの名無しさん
14/05/13 20:58:37.93 Xzl/NzK/
Gitのmasterはrcとはいえpuやnextに比べれば安定してんじゃねーの
あとGitはrcをリリース4 5週間前から毎週出すポリシーみたいだから、
rcの数が多いか少ないかで安定度は測れない。
一応今週末に正式リリース予定ぽいんで、
今週出なければなんかまずいバグが残ってるのかもね。
414:デフォルトの名無しさん
14/05/13 21:43:52.50 HfUZuSMx
gitをコンパイルして入れるときってユーザーはrootでやってますか？
415:デフォルトの名無しさん
14/05/13 21:58:13.25 8hwDbhT0
>>414
コンパイルは一般ユーザー
ディストリは？
416:デフォルトの名無しさん
14/05/13 22:42:01.92 HfUZuSMx
debianです
ソースコードから入れる時って/usr/local/srcにいれてるんですが
ここ一般ユーザーだと書込できないんですよね
おまけにrootにsshの設定をしてないのでgit cloneできないし
rootにsshの設定をするべきではないらしいのでどうするのがいいのかわかりません
417:デフォルトの名無しさん
14/05/13 22:48:27.73 8hwDbhT0
debianなら /usr/local 以下は staff グループになってるでしょ？
なら自分をstaffグループに追加すればいいだけ。
まあ、俺は自分のhome以下でコンパイルするけど。
なんかさ、よくコマンド実行できなかった時、
グループに追加すればいいのに、すぐsudo使う人いるよね。
418:デフォルトの名無しさん
14/05/13 22:49:46.52 tJgFTBc/
ソースなんてどこに入れてもいいし、バイナリやライブラリもパス通ってるならどこでもいい
419:デフォルトの名無しさん
14/05/13 22:49:59.25 tmdhIwHM
なんか呼ばれたような気がしたので
420:デフォルトの名無しさん
14/05/13 23:30:22.27 HfUZuSMx
なんかエラーで全然ここに書込ができません
ありがとうございます
あとはlinxuできいてきます
421:デフォルトの名無しさん
14/05/14 00:59:32.71 N43CNidq
Git の公式の文書ではソースからのインストールの例として sudo を使ってるけどね。
URLﾘﾝｸ(git-scm.com)
422:デフォルトの名無しさん
14/05/14 01:46:24.51 ToGrq+HN
>>410
リリース番号とかなら、CIツールのビルド番号とかでいいんじゃね
423:デフォルトの名無しさん
14/05/14 02:13:25.97 +eGAQ9pX
そもそも自分しか使わない PC で、いちいちグループに追加とかしてると、むなしくなってくるわ
sudo で十分だよ
424:デフォルトの名無しさん
14/05/14 02:48:09.56 LFlUnuUg
sudo & パスワード打つのが面倒だろ？
楽な方を提案してるんだよ。
425:デフォルトの名無しさん
14/05/14 02:49:32.86 TJ8LcHmI
もうrootになっちゃえよ。
426:デフォルトの名無しさん
14/05/14 02:51:54.81 EH48jFeA
侵入されたら即乗っ取られそうなインターネッツですね
427:デフォルトの名無しさん
14/05/14 03:03:17.35 LFlUnuUg
>>425
それはだめ。
root使うなって流れでsudoなんだろうけど、
なんでもsudo使ってたら意味ないって。
そのうち普通のコマンドまでsudo使う癖がつくとかな。
sudoつかってホームディレクトリ以下にファイルやディレクトリを
作るもんだから、自分のファイルを編集できないとかアホなことにｗ
428:デフォルトの名無しさん
14/05/14 04:42:12.31 8Tw5p8Hi
一般ユーザの権限増やしちゃうほうが余程ダメだろ
確かに初心者の頃には自分に弄れないファイル作ったりするもんさ
…でも、そこでそのファイルの所有者を自分に戻す方法や
どうすれば一般ユーザのファイルとして作れるのかを考えず調べずに
「一般ユーザの権限を増やしちゃえ」
ってやるのは思考停止だと思うよ、root常用と発想が変わらない
429:デフォルトの名無しさん
14/05/14 05:13:22.04 TJ8LcHmI
普通にrootでapt-getしてstaffなユーザでgit使ったらいいんじゃないの。
staffグループに入れるのすら嫌うのにsudoersに入ってるってどゆことよ。
430:デフォルトの名無しさん
14/05/14 07:50:49.18 gY3lBZ4/
GUI があって sudoers 弄ってる認識ないとか。
431:デフォルトの名無しさん
14/05/14 07:51:39.21 HVjR+QBF
>>429
> 普通にrootでapt-getして
いちいち root でログインしてるのか？
432:デフォルトの名無しさん
14/05/14 08:16:46.96 1MSvyiHJ
脱線はそのくらいで
433:デフォルトの名無しさん
14/05/14 10:07:15.20 LFlUnuUg
>>431
権限あればいいんだから方法はなんでもいい
須藤でも流宇屠でもなんでもいい
434:デフォルトの名無しさん
14/05/14 10:21:07.79 U/CskQfB
そもそもlinux公式のパッケージなんて古いのに誰が使うんだよ
俺が使ってるのディストリのは1.7だぞ
OpenSSLの件もあるのに今1.9.1以下を使ってる奴は世界の地雷
435:デフォルトの名無しさん
14/05/14 10:50:10.78 tkkbE9ax
権限設定が大雑把すぎる
rootにならないと何もできない
436:デフォルトの名無しさん
14/05/14 11:53:53.82 HVjR+QBF
>>433
>>429 が sudoers どうのこうの言ってるから聞いただけ。
関係無いけど、須藤とか流宇屠とか面白いと思って書いてるの？
437:デフォルトの名無しさん
14/05/14 13:19:05.91 LFlUnuUg
>>436
面白いと思ってるならいちいち確認しにくるなよ
もっと自分の感性に自信持てや
438:デフォルトの名無しさん
14/05/14 14:37:13.29 RXztcnfz
>>427
>なんでもsudo使ってたら意味ないって。
たしかにsudoインフレ気味のきらいはある。
お前もう別にrootでログインしているのと変わらんのと違うか、みたいな。
439:デフォルトの名無しさん
14/05/14 15:57:03.71 z8cZm/fT
スクリプトの中でsudo書いたら負け
440:デフォルトの名無しさん
14/05/14 18:43:36.40 HVjR+QBF
>>437
ひょっとして皮肉って、わからなかったのか？ (w
441:デフォルトの名無しさん
14/05/14 19:12:13.53 56gZpWss
どうでもいい
442:デフォルトの名無しさん
14/05/14 19:45:20.61 LYwl2FB3
相談させてください。
開発ブランチをmasterへマージしたいのですが、
masterブランチがかなり進んでしまい、開発ブランチとの共通コミットがかなり前の物となってしまいました・・・
このままマージすると履歴が見づらいので、masterでリベースをしたいのですが、
開発ブランチにも、沢山のマージコミットがあり、そのままリベースするとマージコミットが吹き飛んで困ります。
マージコミットを残したままで、masterとリベースする方法というのはあるでしょうか？
もし、そのような方法がない場合・・・
どのようにすれば、少しでも見やすい履歴として残してマージする事ができるのでしょうか・・・
よろしくお願いします
443:デフォルトの名無しさん
14/05/14 20:19:17.04 NgeMMujl
マージじゃあかんのか？
444:デフォルトの名無しさん
14/05/14 20:37:04.99 W0xDTkwU
--preserve-merges で ggrks
445:デフォルトの名無しさん
14/05/14 20:38:55.41 W0xDTkwU
だけど俺もマージをおすすめする
446:デフォルトの名無しさん
14/05/14 20:59:04.67 LYwl2FB3
>>443-445
お答えありがとうございます
まさしく、--preserve-merges この機能を求めていました！
本当に助かりました
普通にマージでも、運用はまったく問題ありません。
しかし、あまりに前のコミットからブランチが切れている物なので、
グラフ上でその他のマージしたコミットなどを、またぎまくりで見るのた大変な状態でした・・・
本当に感謝です
447:デフォルトの名無しさん
14/05/14 21:21:30.74 Tc6rr+/g
男なら履歴をいじってんじゃねえよ！
448:デフォルトの名無しさん
14/05/14 22:35:14.87 XlAO72qf
URLﾘﾝｸ(git-scm.com)
ここにTortoiseGitないのは何で？
449:デフォルトの名無しさん
14/05/14 23:23:23.76 LFlUnuUg
>>428
> 一般ユーザの権限増やしちゃうほうが余程ダメだろ
意味不明。
今の話はsudo権限で書き込める人に対して
sudo使うな一般ユーザー権限でコマンド使えるようにしろって話だから。
誰もsudo権限ない人に権限与えろなんて言ってねーよｗ
> …でも、そこでそのファイルの所有者を自分に戻す方法や
> どうすれば一般ユーザのファイルとして作れるのかを考えず調べずに
> 「一般ユーザの権限を増やしちゃえ」
> ってやるのは思考停止だと思うよ、root常用と発想が変わらない
そんな話してないけどねｗ
sudo使って権限を変える行為のがroot常用と同じだから
sudoも使わずに一般ユーザーでやれるようにしろと。
ユーザに必要な権限を与えるのは、必要で許されるならば何の問題もなく、
権限を与えなければ、sudo使うしか無いわけでそれがroot使ってるのと変わらない。
っていうか、sudo常用＝root常用ってわかってる？
450:デフォルトの名無しさん
14/05/14 23:36:27.18 ExP2CQtU
a.phpを修正(50行)した後にb.php(500行)を修正しました
このときgit add a.php; git commit -m "a.phpを修正"したあとにgit checkout -fしたらどうなりますか？
451:デフォルトの名無しさん
14/05/14 23:36:39.56 EH48jFeA
クソニートの戯言はチラシの裏にでも書いてくださいね
452:デフォルトの名無しさん
14/05/14 23:38:18.31 EH48jFeA
>>449宛て
453:デフォルトの名無しさん
14/05/14 23:45:05.68 LFlUnuUg
煽って何がしたいの？ｗ
454:デフォルトの名無しさん
14/05/14 23:48:28.71 PSOih+2g
今週の中学生日記はここですか
455:デフォルトの名無しさん
14/05/15 00:44:28.26 YRo5/B9y
>>449
「どこからがどの権限なのか」を意識しづらいのがroot常用の一番の問題かと。
まあそもそも、もうスレチなんだが。
456:デフォルトの名無しさん
14/05/15 01:08:22.07 p6ZJAeXV
>>449
> っていうか、sudo常用＝root常用ってわかってる？
こういう奴って /etc/sudoers の ALL = (ALL) ALL をおまじないだと思ってるんだろうな...
能力のないものには、いい道具与えても無駄なのがよくわかるな (w
457:デフォルトの名無しさん
14/05/15 01:23:15.29 FUoGOy6E
>>456
本当にsudo常用がroot常用と変わらないの分からないの？
sudo touch a ってやったら、root:rootでファイル作られるよね？
sudoはなるべくrootにならずに、root権限（ユーザー未指定の場合）で
実行するものであって、結局のところrootで実行しているのと同じ。
sudoを常用したら意味がないんだけど。
なんでもかんでもsudo使って"root権限で実行"するのではなく
適切な権限を指定しなさいと言ってる。
458:デフォルトの名無しさん
14/05/15 01:45:41.47 p6ZJAeXV
>>457
> sudo touch a ってやったら、root:rootでファイル作られるよね？
お前俺のレスの意味わかってないだろ (w
touch でファイル作られるのが嫌なら禁止すればいいだけ
ALL = (ALL) ALL って書いといて、root 常用と同じとか、バカすぎ
459:デフォルトの名無しさん
14/05/15 02:11:34.74 t+uv2X5h
「俺のレス」
くさかべ先生が怒りそう
460:デフォルトの名無しさん
14/05/15 02:39:04.28 mVM4WfmV
そういうことにしたいのでつね
461:デフォルトの名無しさん
14/05/15 03:28:24.48 FUoGOy6E
>>458
お前根本的に間違ってるじゃんか。
/usr/local/srcへの書き込みだぞ。
実行コマンドを制限してどうする。
こういう時はグループで書き込み権限を与えるんだよ。
sudo使うにしても結局グループ使うんだから、
sudoの前にまずグループだろうが。
462:デフォルトの名無しさん
14/05/15 07:07:31.46 p6ZJAeXV
>>461
> /usr/local/srcへの書き込みだぞ。
俺はそんな話してない。
俺は、
> っていうか、sudo常用＝root常用ってわかってる？
がおかしいって言ってるだけ。
ちなみに sudo はグループでもユーザーでも指定して制御できるから
> sudo使うにしても結局グループ使うんだから、
は、根本的に間違ってる。
なので、
> お前根本的に間違ってるじゃんか。
これはお返ししておくよ (w
463:デフォルトの名無しさん
14/05/15 07:10:12.05 ARfjiSB0
ブランチ名に日本語使ったりする？
464:デフォルトの名無しさん
14/05/15 09:03:46.47 FUoGOy6E
>>462
> 俺はそんな話してない。
そもそもそれが間違ってるじゃないか。
話の流れを読め。
最初の >>416 は ファイルを書き込む権限の話。
> ソースコードから入れる時って/usr/local/srcにいれてるんですが
> ここ一般ユーザーだと書込できないんですよね
>>428 でもファイルを書き込む権限の話。
> 一般ユーザの権限増やしちゃうほうが余程ダメだろ
> 確かに初心者の頃には自分に弄れないファイル作ったりするもんさ
最初っから、ファイルの権限の話なんだよ。
465:デフォルトの名無しさん
14/05/15 09:14:11.31 8qQimVf0
sudoをroot権限を与えること以外で使うなら
setuidで十分な事が多くね？
466:デフォルトの名無しさん
14/05/15 10:08:52.62 uV6K9eLe
/usr/local/srcを一般ユーザーに権限与えるのってLinuxの意に反してないの？
rootしか書き込みできないのは意味があってそうなってるんじゃないの？
467:デフォルトの名無しさん
14/05/15 10:20:43.45 yW4QL04N
>>466
staffなら書き込めるんだからそれこそが意だろ。
本当の一般ユーザをstaffにするのはおかしいが、
それならそもそもsudoも使えないべきだし。
468:デフォルトの名無しさん
14/05/15 11:05:33.69 l/v1SCMb
>>463
使わないなあ
469:デフォルトの名無しさん
14/05/15 11:22:14.76 uV6K9eLe
sqliteのデーターベースファイルに日々データを追加しているんですが
これもリポジトリで管理したほうがいいですか？
GitHubでこのファイルをみたことがないのでどうしたらいいのかわかりません
バックアップが目的なのでデータベースファイルを使ってるプロジェクトだけはzipで固めるべきか
470:デフォルトの名無しさん
14/05/15 11:46:35.53 8MS98tJI
>>464
> 話の流れを読め。
そんな話には興味がない。
俺は単に、
> > っていうか、sudo常用＝root常用ってわかってる？
がおかしいって言ってるだけ。
まあ、誤魔化そうと必死なのは伝わったよ (w
471:デフォルトの名無しさん
14/05/15 11:55:39.44 WbHEhbR4
>>469
バイナリだと差分が見えないからsql文をバージョン管理するとかになるのかな？
ダンプがそのままsql文にならなかったっけ？
面倒なら定刻にダンプするスクリプト走らせとけばいいかもね。
472:デフォルトの名無しさん
14/05/15 14:32:57.85 R166abH9
>>466
/usr/local/ 以下は、自分がPCを持っている人の話
WinのOwnerみたいなもの
473:デフォルトの名無しさん
14/05/15 18:07:08.81 Q6tngT9B
testブランチからmasterブランチにマージすると
testブランチのコミットログがmasterブランチのコミットログと合体しますよね
だからここのスレの先輩方はrebaseしろって書かれているのでrebaseしようとおもうんですが
rebaseしたらtestブランチのいままでのコミットログはgit logで見れなくなりますよね
474:デフォルトの名無しさん
14/05/15 19:20:39.33 dmANjRi5
>>463
俺はめちゃ使う。
むしろ英語は使わない
>>473
見れるけど・・？
よくわからないなら、rebaseはやめてmergeにしておくのがいい
475:デフォルトの名無しさん
14/05/15 21:37:37.22 7ICa3Xuq
>>465
-gで、プライマリグループを変更して実行することはある。
newgrpとかsgコマンド知らなかったから。
すれ違いなのはわかっているがこれだけはいわせてくれ
passwdとsudordersの編集は、実行できないようにしとけ？
476:デフォルトの名無しさん
14/05/15 22:41:35.54 FUoGOy6E
>>470
それで、sudo使う時ってどんな時？
あんたは常用してるんだよね？
477:デフォルトの名無しさん
14/05/15 22:42:32.59 FUoGOy6E
>>467
> staffなら書き込めるんだからそれこそが意だろ。
そういうことだね。
debianではちゃんとグループが設定されている。
だからsudoを使うことは殆ど無い。
478:デフォルトの名無しさん
14/05/15 23:02:53.18 8MS98tJI
>>476
俺が常用してるかどうかなんて関係無いでしょ？
難癖つけようとしてるのバレバレですよ (w
479:デフォルトの名無しさん
14/05/15 23:07:56.03 UtPqEVIk
クッソくだらん喧嘩をだらだら続けるな
480:デフォルトの名無しさん
14/05/15 23:08:02.02 FUoGOy6E
あ、常用してないんだｗ
481:デフォルトの名無しさん
14/05/16 09:08:26.94 CZd6eAcT
FUoGOy6EはNG登録した
482:デフォルトの名無しさん
14/05/16 10:34:06.37 ORK55gYr
NG登録した = もう反論はしない（見えないからできない）
なんだけどわかってるのかなぁ？ｗ
まあ、反論なければそのほうが俺は楽でいいけど。
483:デフォルトの名無しさん
14/05/16 15:03:25.79 7k6X61nc
荒らしに対抗できる唯一の手段は「反応しない」だからね。
ってひょっとして>>482はその荒らしか
484:デフォルトの名無しさん
14/05/16 15:43:20.57 T7U0JNMD
「反応しない」っていうのならレスするなよｗ
自分で言ったことぐらい守りましょう。
485:デフォルトの名無しさん
14/05/16 17:56:52.11 w4POSpYE
C:￥ripo￥bbs￥.gitがリポジトリとします
これでコミットしまくったらコミットログがたまりますが、この状態でGitHubプッシュするとすべてのコミットログもGitHubにあがりますよね
朝昼晩とコミットしていてちょっと知り合いにコミットした時間を見られたら困る事情があるので
プッシュするまでのコミットログを全部まとめて一つに書きなおして毎日17:00にコミットしたことにしたいのですが、
いまあるコミットログはgit logで見られるようにしておきたいのでいじらずそのまま残しておきたいのです
こういう場合はどうしたらいいでしょうか？
486:デフォルトの名無しさん
14/05/16 17:58:05.13 w4POSpYE
17:00にコミットというのは自分でコミットをするものだとお考えください
自動でコミットさせるという意味ではありません
とくに17:00ぴったりというわけじゃなくて夕方過ぎにコミットするものとお考え下さい
487:デフォルトの名無しさん
14/05/16 19:26:11.51 XlirJvLT
夕方にしたコミットにsquashで朝昼のコミットをまとめればいいじゃないの
488:デフォルトの名無しさん
14/05/16 19:28:33.38 XlirJvLT
コミットを自分のとこだけ残しておきたいならプッシュしないブランチを作ってそこで開発すればいいのよ
そのブランチからプッシュするブランチへマージするためのブランチを作ってそこでrebaseなりsquashなりでまとめてプッシュするブランチへマージ
そんでもってブッシュするの
489:デフォルトの名無しさん
14/05/16 21:25:42.84 eLIAKwa7
rebaseしてもauthor dateは変わらないんじゃなかったっけ？
490:デフォルトの名無しさん
14/05/16 21:50:47.36 T7U0JNMD
コミット内容を修正すればさすがに変わるし、
reset authorすればよい