1 ：
デフォルトの名無しさん ：
2010/09/14(火) 21:38:18 あら、レスをそのままコピペしちゃった
『ぎっと』ですか『じっと』ですか
gは大文字なんだっけ？ロゴは小文字だけど。
名前としてはGit
Git は何の略ですか？
Gitの略です
丁寧にありがとうございました
略じゃないw
cogitoは何と読むべきでしょうか
18 ：
17 ：2010/09/19(日) 22:13:10
branches/releases/はその下にバージョンを名前にしたフォルダが入っているのに、
結局Windows用GitはmsysGitを入れればOKと色々なブログとかに書いてあるが、
>>20 その人も違いがわからんといってました。
両方入れてみたところ頭にmsysが付かないほうはGUIがあるみたいでした。
ではmsysが付くほうのメリットは？
また両方入れて問題はないでしょうか？
とりあえず、Git（またはmsysGit）＋TortoiseGitの組み合わせにしようと思います。
前スレ974のこぴぺ
https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit > What is msysGit?
>
> msysGit is the development environment to compile Git for Windows.
> It is complete, in the sense that you just need to install msysGit,
> and then you can build Git. Without installing any 3rd-party software.
>
> msysGit is not Git for Windows; that is an installer which installs Git -- and only Git.
>
> It is easy to see the difference: the installers for Git have the prefix Git-,
> the msysGit installers have the prefix msysGit-.
> Another telltale is that the msysGit installers come in two flavors: fullinstall and netinstall.
> Further, msysGit does not install to C:\Program Files by default.
> But msysGit comes with gcc, the GNU C Compiler.
>
公式のDownloadにWindowsとMacの項目が増えたね
Gitについて前から疑問があるのですが、誰かご存知でしょうか？
蝙蝠本P42-44にsha1の衝突の可能性について書いてあるが
まあ原理的には基本アウトだよね
百万が一というより10^48が一だが
29 ：
25 ：2010/09/25(土) 14:19:35
ありがとうございます。
ハッシュの万能さ加減がGitの要になってるから、
msysgit1.7.2.3とTortoiseGit1.5.3.0で使っていますが
>>31 これってRebase.cherry-pickしようとしたら落ちる？それともした結果のもの？
>>28 えっと･･･もう少し具体的に
何分の一？
34 ：
33 ：2010/09/25(土) 16:58:12
Googleに"10^48 in 日本語"と聞いても教えてくれない・・・
35 ：
33 ：2010/09/25(土) 17:00:30
SHA1は2の80乗個のハッシュを作ったらどれか1個だけが50％で被る
つまり、とりあえず生きてるうちにそういう状況にぶつかれる可能性はほとんどないってことだろwww
確率論とは悲惨なもので、どんなに天文学的な確率を弾き出してても実際に起こるときはやっぱ起こる
どう見ても、ハードディスクやマシンの故障とかを気にするべきw
DAGだから親がいないみなしごになるだけじゃ？
どうなんだろ、オブジェクトIDがダブった時点で
一番リビジョンが多いのはやっぱりLinuxカーネルなのかな？
>>42 それはニュースになるでしょう。
カーネルがどうこうではなく、sha1ハッシュの脆弱性が考えられるから。
すでにあるのと重複チェックは重くてできないか。
>>43 いや脆弱性も何もカブるのは単純な確率の問題
カブらないことは原理的にありえない
脆弱性とか関係ない
もし意図的にハッシュ値を同じにしたというのなら、昔ならニュースになった
今はSHA-1は既に現実的な時間で破られてるからニュースにもならない
>>45 俺もあなたと同じこと思ったけど（書き込みまでしそうになったｗ）
>>43 の人もそれは分かってるから、「脆弱性が考えられる」なんて
まわりくどい書き込み方したんでないの？
「現実的にはほぼ衝突しない、だが衝突した、これは果たして
本当に"運が悪かった"だけなのか？」という意味でニュースになるだろうと。
ハッシュのコリジョンよりgitのバグの方を気にしろ、って事だろう
hgも同じ感じのハッシュだけど、bzrはコミットユーザと時間とハッシュの連結みたい
もし衝突したら、話題にはされるだろうけど、
可能性がゼロじゃないってだけで不安になるのは職業病だから仕方ないと思うけど
>>50 落ちるかもわからない隕石は放っておいて、
もし落ちたら落ちたでその後処置すればいいわけですね、わかります
54 ：
デフォルトの名無しさん ：2010/09/26(日) 02:39:26
人間いつか死ぬんだし
ム板に来ると変なのが出てくるけど、文字コードの話はまだ？
衝突するかもしれないようなものを衝突しないとして設計しているのはバグのある
>>57 bzrってハッシュにユーザ名と時間くっつけてるんでしょ？
衝突の可能性としては同じだと思うんだけど。
ハッシュ値が一度でも被ったなら、そのシステムの「被り回避」は信用ならない
てゆーかだな、
ム板らしくなってきました。
ハッシュ値の件だけど、将来のバージョンでSHA-256とかが使われる余地はあるんだろうか
それはGitの次のアーキテクチャだと思う
gitに限らず、普通にハッシュが衝突したってだけでそれなりの話題になるのは必至だろうな
65 ：
31 ：2010/09/26(日) 18:12:35
>>32 しようとしただけで落ちます。
ログ一覧からRebase(cherry-pick)を選択しただけで落ちます。
Git1.7.1なら大丈夫みたいなのでしばらくこれで行こうかと思います
>>65 した結果が見えているんなら、TortoiseGitのバグだろうね。
>>60 同じ所有者が同じタイムスタンプでcommitする操作なんてまずしないから
十分有効な回避策のはずですが。
git信者ですか？
>>68 commitの--dateというオプションと
GIT_AUTHOR_DATE, GIT_COMMITTER_DATE 環境変数で時間なら操作できます
rebaseだと時間順に並ばないから意味無いんだけどね
>>68 「まずしない」ということが何を意味するのか、ハッシュ値の衝突が
「まずしない」と比較してどうなのか、考えてみよう。
72 ：
デフォルトの名無しさん ：2010/09/27(月) 21:48:32
フロッピーの時間操作なんかまずしないもんね
ユーザ名+時分秒+ランダム数字4ケタ くらいでまず重複しない
ぐへへ・・・タイムスタンプを衝突させてやるぜ
ユーザー名とタイムスタンプで十分なのならハッシュ値なんて面倒なものそもそも使わないと何度でも何度でも言う
というか、
gitは日本で作られたの？
そもそも外国製
>>76 意図的にできるということと、偶然そうなってしまうということの違いを理解できない
人がいるということに問題を感じる。
最近gitを使い始めたのですが、よくわからないので質問させてください。
>>80 Git的には意味不明だから、日本語で詳しく書くか、チュートリアルぐらい読んだ
ほうが良いと思う。
>>80 はbzrの共有リポジトリを言っているんじゃないかと思う
>>81 ,82
返答ありがとうございます。
>>81 基本的に、各ユーザは自分の作りたいものに対するプログラムを書く予定です。
なので、本来は別々のリポジトリに分けた方がよいのかと思うのですが、
・ユーザが増えるたびにいちいちリポジトリを作るのが面倒
・利用者が自分でリポジトリ作るというのも避けたい（権限的な問題）
と考えてます。
なので、一つ全体的なリモートリポジトリを作っておき、その下にあるユーザ毎の
ディレクトリに対してローカルリポジトリをコミットできれば良いかと思いました。
そもそもめんどくさがるなという話なんですかね、これは。
>>82 Bazaarはディレクトリごとに管理してるんですね。
こっちならこのようにできそうな気が・・・。
少し調べてみます。
>>77 >>78 日本人と言っても在米１５年以上の在米邦人だ。
現在はGoogle社員。
>>83 Gitosisみたいなのでホスティングすればそういうのできるよ。
>>84 どっかのプロフィールではTwin Sun所属ってことになってたと思うんだけど、
ヘッドハントされたのかな。
git svn でcloneしてくるときに、通常は --stdlayout, -sで持ってくると思いますが、
>>83 >>85 じゃないけど、github使う(privateや容量増は有料だけど)のもいいね
githubはユーザーごとに簡単にリモートリポジトリもてて
管理用のユーザーかリポジトリ作っておけば、そっちにも成果をマージできるでしょ
あとは、どこかのサーバーに中央リポジトリ用意して、
各個人ごとにリモートブランチきって突っ込むとかｗ
タグ一覧するコマンドって無いのかな？
gitはSSHと組合せて使っている人が多いと思いますが
v1.7.3.1きた。stash が壊れてたらしい。
告白というか、一緒に下校してほしい、みたいな感じ。
これはひどい誤爆…
甘酸っぱいのうｗ甘酸っぱいのうｗｗ
gitのスレタイで来たのなら、高度な誤爆
gitってあほ、ぼけ、間抜けって言う意味なんだねｗ
なんだ俺のことか
お前は間抜けなんかじゃないよ。自信を持とう。
そうだ、お前は間抜けでも歯抜けでも毛抜けでもない！
欝だ死のう
話の流れをブッタギル様ですまん。
git commit -m '#!/usr/bin/hogeを#!/usr/local/bin/hogeに変更' とか？
運用次第だと思うが、git推奨はどんなのだろう
>>102 例えばそれが「インデントまとめて変更」とかだったら100ファイル一発でも
良いと思うが、100個のバグ修正だったら絶対に分けるべきだと思う。
俺の考えでは、誰かが分離したくなるかもしれない単位、で
世に出すのが良いのではないかと思う。
106 ：
102 ：2010/10/08(金) 09:03:57
そゆ意味じゃ、テストスクリプト群への同様の修正なので、
そもそもなんで同じ内容のものを100箇所に鏤めて置くんだ？
テストプログラムに対するレビューは果たして必要か
わかった、じゃあスレ違いじゃない書き方にする。
>>109 他人のテストスクリプトに対してそういうケチを付ける気にはならないな、自分は。
っぷっ
rebaseしたら今いるブランチの最後のコミットだけ無くなった
はぁ・・・復元する方法ないのかな・・・
reflogすれば見つからないか？
>>112 ふつーは reflog でちまちま探すなんだけど、rebase する前にあらかじめ
git checkout -b b4rebase rebased みたいにくさびブランチを打っておくとよいぞ。
つか rebase がもっと柔軟にならんかね。って欲張りな悩みよね。
カキコついでに質問だが、カスケードしたブランチを一発で rebase するいい方法、ない?
>>116 rebase -i はけっこう柔軟だと思う。
>>117 普通に git rebase master qux じゃダメなん？
>>118 git checkout foo; git rebase master
git checkout bar; git rebase foo
git checkout baz; git rebase bar
git checkout qux; git rebase baz
と同じ結果にならないよね?
各ブランチがレビュー待ちのパッチを含んでいると想像してくれ。
言い忘れ。かつ、各ブランチがそれぞれのマイルストーンを達成している。
>>119 それをコマンド一発でやりたいってこと？
branch.name.mergeを元にして動くスクリプトを書いても良いと思うけど、
mergeと違って、元がrebaseしてる場合はコンフリクトする可能性大だから、
複数ブランチを一気にrebaseかけるのは怖いな。
手動でやったほうが良いんじゃないかね。
foo、bar、baz、quxはそれぞれテスト等も済んでるだろうから、
無理にrebaseするよりも、masterからfooにmergeしたほうが良いと思うな。
各ブランチがmasterの新機能を前提として必要になったのなら仕方がないけども。
濱野さんの入門Gitには、そのように書いてあった。
なかなか上流に取り込んでもらえないと、rebaseでキレイに並べて
おきたい気持ちは分かるんだけど…
master ブランチにいるとき git merge origin で origin/master->master のマージが行われないのなんでだよ!
>>122 git pullなら省略できる（適切に設定されてれば）
すげー書き違え! まさにその git pull origin でカレントじゃない master の更新が行われず、
自演乙
TortoiseGitをプロキシ経由で使うのってどうやれば？
うちでは正常に動作するよ
PuttyってことはそれってPutty側で設定がいるんじゃ
git svn で取得したリポジトリにて git describe がタグ振らずに機能するといいなあ。
git commit -aを実行するとVimが起動します＞＜
git commit -aを実行するとjedが起動
git commit -aを実行するとパソコンが固まります＞＜
もしかして、日本語でログメッセージ書くとStashに失敗する？
なんかgit svnで取得したリモートブランチに対して、直接mergeをかけたら
>>134 今のところSVNでgitのマージコミットを表現することはできないから、
dcommitする予定のブランチではmergeしちゃダメだよ。
まず今のブランチをgit svn rebaseでSVNに追随させないといけない、んだけど
うまくrebaseできなそう。。。
git checkout -b mergetest git-svn してcherry-pickで整形し直したほうが
良いかもしれない。
>>135 いや、svn側の変更をgitで追いかけているだけなんで、dcommitする予定はないんだ。
手元にはsvn fetchしているだけのリモートブランチ(デフォルト名のままgit-svn)と、
ローカルの変更込みのmasterがあるだけ。
cherry-pickしたほうがいいのかなあ。ありがとう。
no-ffつけるとかそういう話じゃなくてか
no-ffはsvnブランチ間のマージの話だったように思うけど……今度試してみる
>>136 >>134 をよく見たら --squash してるけど、前回もそうしてた？
それならコンフリクトするのも分かるよ。
squashで別のコミットとして作り直してるから、次にマージする時には
また同じコミットが対象になってしまう。コンテンツの内容が近いなら
うまい具合にマージ出来るかもしれないが、失敗する可能性も高い。
これはgit-svnに限らないgitの話。
git log master..git-svn で見ると既にマージ済みのが出てくるんじゃないかな。
前回merge --squashしたところからの三点マージができればいいんだけど、
>>140 ＞やってることはリモートブランチがsvnなだけで
http://progit.org/book/ja/ch6-7.htmlと変わらないと思ってたんだけどなあ 。
その例はsubtreeマージで１方向なので、2ツリーマージでもうまくいくんだと思う。
>>141 ＞どうせsvn側でしか変更はないんだから-Xtheirsでも付けるかな……。
一方的なコピーでいいのかな。それなら merge -s subtree でもいけそう。
＞そもそもgitで三点マージを行うのがrebaseか……。
rebaseも普通のmergeも、共通の祖先が見つからない(2ツリーマージ)場合は
ファイル単位でぶつかると手動マージになる可能性が高いね。
＞前回merge --squashしたところからの三点マージができればいいんだけど、
無理矢理やるとしたら…
git read-tree -u -m 前回squashしたコミット HEAD git-svn
とかで3wayいけるけど、ファイル同士がぶつかるとunmergedになってしまうので
自分でどうにかするとか、git merge-index他の配管コマンドでどうにかしたりする必要あり。
read-treeに-mなんてあったのか。次からそれでやろう。ありがとう。
ブランチaで8個ほど一つ一つ丁寧にコミットして
リモートリポジトリに真っさらなブランチをpush --forceしてしまいました
>>146 まず手元のリポジトリで git reflog してみる。それで見つかるかも知れない。
手元に無くても、分散してるどこかにあるかも知れない。
最悪のケースとして、pushした先のリポジトリにしか無かったという場合、
まずその.git（bareリポジトリならそのディレクトリそのもの）をバックアップ。
git fsck --lost-found を実行すると .git/lost-found/commit が出来るので、
そこから探す。
あまりあり得ないと思うけど、空pushした後に git gc が実行されていると
ポインタだけじゃなくてオブジェクトも消えているので、もうダメぽ。
GitExtensions使ってる人いますか？
そんなのあるのか、使ってみよ
過去の履歴を綺麗さっぱり消したいのですが可能でしょうか？
>>150 ほんとに綺麗さっぱりなら.gitを消してinitしなおすのが簡単だね。
微妙に残すのなら、git checkout --orphanというのがあるので
これを利用すればrootコミットから作れる。
なんか、こういうことをやりたい、ってのが先にある時にやり方が分からないことが多いのは
むしろgit使ってみて今までやりにくかったことが簡単にできてびっくりしたけど
Subversion使っていてこういう機能欲しかったんだ、というのがあったり
TortoiseSVNからコマンドラインに移行したのも理由だと思うが
ただ、
>>152 がいうのもわからなくはなくて、〇〇はrebaseでできる、といった場合に、
何故○○というコマンドじゃないのか？と思ったり、
もちろん基本的なコマンドは用意しとくから、各個人勝手にaliasしろや、
という一貫したなげやり感もUNIX的にはわからんでもないし、
出来る事多いからコマンドかなり増えるだろうし。
Bazaarは確か標準のaliasもあるしかなりコマンドあったはず。
どっちがいいかという話だな。GUIがメインならコマンド多くても気にならないんだけどね。
gitは、もしPro Git（の日本語訳）がなければ、少しでも難しいことは
便利そうなんだよなあ。
Mercurialってどうなの？
Mercurial は分散で高速なんだけど凝ったことしなきゃ svn なんかとそんなに変わらない感覚で使える。
ほー。今度使ってみようかな
hgは基本機能は限定されているけど、hgに同梱されている拡張のMQを使えばほぼgitと同じことができる。
>>160 名前付きブランチってどういう感じのもの？
>
>>160 > 名前付きブランチってどういう感じのもの？
１つ１つのブランチにリビジョンの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
すまん。肝心な所で間違った。
誤）
１つ１つのブランチにリビジョンの名前が埋め込まれている。
正）
１つ１つのリビジョンにブランチの名前が埋め込まれている。
>
>>160 > 名前付きブランチってどういう感じのもの？
１つ１つのリビジョンにブランチの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
>>163 なるほど、なんか分かった。確かにGitはブランチの名前自体には意味を持たないので、
最初使い始めの頃はそこに戸惑った気がする。この変更ってどこから（どのブランチから）
来たんだろ？って思った時によく分からないんだよね。
マージコミットのログメッセージにブランチ名が書かれるから、gitkとかで視覚的に見れば
なんとなく分かるけど、それでもFast-forwardだったりすると完全に統合されちゃうから、
masterでやった作業なんだかtopicでやった作業なんだか、一見分からない。
俺も１人で開発する時はmercurialだな。
GitExtensionでgit rebase -i 相当のことをするにはどうすればいい？
Subversionのときはコミットミスっても気にならなかったが、
gitだと下手に直せるからつい気になるわ
>>164 履歴をフラットにしたくて気軽にrebaseすると、rebase前のブランチなくなって焦るわｗ
仕様上、当たり前なんだが
cherry-pickするか別のブランチ名つけろ、というのはそうなんだけど
>>164 そこで git merge --no-ff
fast-forward の意味がいまだにわからない‥‥
>$ git checkout master
>>169 fast forward＝ブランチのポインタをずらすだけ
分岐してなければ、これでいけることが多い
分岐しててfast forwardしたければ、rebaseしてコミットを直線にして分岐なくせばfast forwardできるが、
以前のブランチなくなるから注意。
これ防ぐには別のブランチ名つけておけばよかったはず。
そういえばpush(git svn dcommit)したあとに間違えてgit commit --amendしてしまっていて、
fast forwardなmergeができずあとから気づいてあせったことある。
rebaseだと駄目で、cherry-pickでamendした分を飛ばして解決したが他にいい方法合ったのか
分かった気がする
git checkout の対象がブランチか、ディレクトリか判断つかないとき
>>172 fast-forward mergeとそうでないmergeは、gitk --allでマージ前とマージ後を見ながら視覚的に確認するとわかりやすいよ
gitk --all やってみたらマージで混乱してた頃の
書いてたらgit関係ないことに気づいたけどそのまま投稿するね
githubのpullリクエストの現在の挙動は、
ブランチ単位で説得して、ブランチの中のどのコミットを採用するかはまぁすたぁに任せる
このへんの作法みたいなのの説明ってあんまりないよね
パッチはメールの本文にベタで置かないと読まないとかいうプロジェクト管理者もいるし、
gistが壊れてないか？
700000番から直ったみたい>gist
git cvsimportを始めてからもうすぐ20時間。
俺も以前cvsimportしたことあるけど、めっちゃ時間かかった上に
git svnも小さいプロジェクトなのに最初のcloneに小一日かかったわｗ
cherrypickのたびに1文字1文字コミット名を入力するのが大変なのですが，
>>188 ターミナルからコピペするの楽だから大変と思ったことないな。
master~5みたいな記法使ったらどうだろ？
ああそうか、現在表示してるコミットのハッシュ値をマウス等でコピーできない環境なのか
マウスなくてもscreenでコピペしてる。
最初の2文字ぐらい打てばほぼ一発補完できるeshellというかEmacs最強
環境はMacです．
>>194 マウス使わないなら尚更screenがいいよ
てかSHA1を直打ちしなくていいように refs/heads があるんだと思うんだが、、、
>>196 こんなのあったんだ。
これってローカルのブランチ名と違うの？
ローカルのブランチ名に近い範囲だったら
>>190 の記法でいけるんじゃないの
>>197 ローカルブランチと同じだよ。
refs/heads/～とかrefs/remotes/～とかはそこまでを省略して指定することができる。
ちなみに.git/HOGEHOGEとかを勝手に作ってもgit log HOGEHOGEとか出来ちゃう。
へぇー、ORIG_HEADって定数が使えるのも .git/ORIG_HEAD の中を見てたってことなのか。
ということは.gitをgitで管理すればブランチの変異もバージョン管理できるわけか
>>179 githubについてはドキュメント足りないよね
pullリクエストを送るボタンの押し方なんて本気でどうでもいい
pullリクエストとして送る予定のコミットのいい書き方とか
pullリクエストの受け入れ方とか吟味の仕方とか説明がない
>>194 一意に決まる場合はハッシュの頭数文字だけの入力で適切に処理される。
今試してみたら、最低でも４文字は必要ぽい
git add .
git reset head で、いいんじゃないかな
>>205 あれ？それでいいんだ
いけました
ありがとうございました！
207 ：
デフォルトの名無しさん ：2010/11/27(土) 13:17:58
複数のサブプロジェクトをひとつのリポジトリで管理するときの指針やコツみたいなのがあったら教えてください。
>>208 そういう意味じゃないんじゃない？
submodule とか？ でもあんま使い勝手良くないんだよねぇ。
Gitならこの人に聞け！
A：共用リポジトリ（自動的にDにプッシュ）
リモートのリポジトリって1個じゃだめなの？
＞RepoBにプッシュすると怒られてしまう
RepoBをなぜ使用しているかというと
開発者各自はどうせ自前の作業用リポジトリを持つんだろうから、
>>215 個人用のリポジトリRepoBを外にも持つ理由がわからない。
冗長性を保つためだけの存在なら、ローカルから直接本番のリポジトリRepoAにプッシュせず、RepoBでブランチ切ってmasterへのマージ時にRepoAへプッシュするようHookさせたらいいんじゃないか？
>>210 とりあえず@bleisさんという人が詳しいみたいです。
どんな人か知りませんが。
マスタがsvnだとどうしてもrebase主義にならざるおえない。…追えない!?
はいはいワロスワロス
>>220 ﾅｶｰﾏ
git svn使うときはrebaseしまくりだわ
でも最近面倒なのでsvnにあるまじきリモートブランチ切りまくり
svnの人が居ると最終的にsvnにrebaseしないといけないのって泣けてくるよね。
無理にgit-svnで連携させようと思うのがいけないのだと悟った
それって削除ファイルがあったときにめんどくね？
コンフリクトした時も痛いことになりそうだ
svnからupdateする時はその都度branchを切るな
>>228 やたらオサレだな。gitもマカーにかかればこうなるのかｗ
まだ使ってないから見た目でしか判断できないけどこりゃ…すごい…
こりゃいいなｗ
git mergetoolでP4Merge使ってるんだけどマージした後にgit statusすると
>>230 Queen最強、と思ってたらKnightによくヤられる
紹介しておいてなんだけどMacじゃないから試せない・・・
GitX風だな。
これいいとおもったらコミットメッセージ日本語うてないなｗ
git-svnには完全には対応してないだと！？まーしょーがないか。
239 ：
デフォルトの名無しさん ：2010/12/07(火) 09:11:31
>>4 これが日本語ファイル名を扱う唯一の手段？
みんな日本語ファイル名をどうやって扱ってるのかな？
コードは日本語ファイル名はないと思うけど、ドキュメントとか普通日本語でしょ。
ドキュメントはバージョン管理しないの？
240 ：
デフォルトの名無しさん ：2010/12/07(火) 09:27:13
追記
242 ：
デフォルトの名無しさん ：2010/12/07(火) 09:42:31
ヨハネスやる気無さ杉だろ
SVNはちゃんと日本語ファイル名扱える(Linux/Windows間でも問題なし)のだけど
パスとログはUTF-8と決まっていてクライアントが自動的に変換してる
なんでGitだとそんな簡単なことが出来ないんだろう
まあ少なくとも
>>245 違うよ。LANGで勝手に変換しちゃうんだよ。大きなお世話、勘違いだけど。
それが簡単だと思っているんなら、SubversionかBazaar使って満足していれば？
エンコーディングを自動判定してるなんて一言も言ってないのに
>>249 SubversionとBazaarがLANGで勝手に判定する勘違いアプリってこと
日本人でさえ混乱してるのに
あらゆる意味で「日本人しかうまく作れない」と思う
>>240 クライアントが「SJIS」のWindowsマシンは世界中どこにも存在しない。
CP932ならあるけど。
254 ：
デフォルトの名無しさん ：2010/12/07(火) 16:47:20
>>253 Microsoft コードページ 932（以下 CP932）は、マイクロソフト及び、MS-DOS の OEM ベンダが Shift JIS を独自に拡張した文字コードである。また同時に、CP932 は Shift_JIS の Windows アプリケーションにおける「実装」を指す用語であるとも言える。
シフト JIS
JIS X 0208 符号化文字集合を一定の規則に従ってシフトした文字符号化方式。具体的な内容は JIS X 0208:1997 に「シフト符号化表現」として記載がある。しかし、文脈によってはベンダ拡張されたコードセットを指している場合もある。
Shift_JIS
「シフトJIS」の IANA 登録名。
255 ：
デフォルトの名無しさん ：2010/12/07(火) 16:48:18
これも
だから何？
257 ：
デフォルトの名無しさん ：2010/12/07(火) 16:51:00
文盲乙
SJISじゃなくてCP932って言いたいだけちゃうんかと
259 ：
デフォルトの名無しさん ：2010/12/07(火) 16:54:43
しかし、文脈によってはベンダ拡張されたコードセットを指している場合もある。
>>240 > 追記
> クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合
Linuxが主環境のgitスレに書き込むのなら、きちんとお勉強してから書き込みましょう、ということ。
261 ：
デフォルトの名無しさん ：2010/12/07(火) 16:59:14
まず日本語の勉強したほうがいいんじゃないですか？
261 ：あぼーん [あぼーん] ：あぼーん
>>261 「クライアント」の意味が分からないので教えてください
それは えいごです
> クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合
エスパーすれば、それをLinux上でもcloneしたりするんだろ
CP932
>>267 すっげえ単純に言うと、
コンピュータのメモリが有限で、
なおかつ帳簿を印刷するための文字が互いに足りなかったから
一昔前のPHSとケータイの絵文字競争に近い
「○○が表示できる」という理由でPHSやケータイを切り替えたのと同じ事が、
昔はコンピュータシステムレベルで起きた
>>239 cygwinのgitでUTF-8で使えば大体いける。
少なくともUTF-8のLinuxとWindowsの間では自分の使っている範囲ではいけてる。
Mac OSXはシラネ。
よく比較対象に上がるけど、Mac OSXとLinux、Windows間はSubversionやBazaarでも大丈夫なのかよ
盛り上がっているところ失礼します。
272 ：
271 ：2010/12/08(水) 14:30:00
merge がconflictして mergeが面倒なだけなら、そのCRLFのリポジトリのファイルを
>>270 > Mac OSXはシラネ。
> よく比較対象に上がるけど、Mac OSXとLinux、Windows間はSubversionやBazaarでも大丈夫なのかよ
大丈夫じゃないよ。SubversionやBazaarは、ファイル名にUnicodeを使っていれば大丈夫だと思っている情弱向け
それでもgitよりsvn,bzrがマシなのに変わりは……
git reset --hard
>>276 コミットしてなくてもgit add済みだったならgit lost-found で捜せば見つかるかも知れない
git reflog -5
~/src
あるディレクトリ以下の
cpp と cxx まぜてんのかい。
283 ：
デフォルトの名無しさん ：2010/12/11(土) 11:27:13
Gitで特定のファイルのみ管理したいときに、
れっつごーまいうぇい！
addし忘れ多発しそう
git submodule
ssh 経由で使うとsubmoduleがうまくpullできない
git svn dcommit
>>289 git svn dcommitする前にgit svn rebaseするべき
git svn rebaseって使っても大丈夫なのかな・・・と思うので
くろうしてるなー(ぼうよみ
git svn rebaseって要はsvn updateでしょ?
もうperforceにするわ
gitで共同開発する場合、
bare やめて detached commit をチェックアウトしておけばドッペルゲンガー
>>295 そもそもgitも特定の共有リポジトリを作ることの方が邪道。
298 ：
295 ：2010/12/14(火) 22:07:53
>>296 >>297 ありがとうございます。
＞detached commit
これは初めて聞きました。
＞そもそもgitも特定の共有リポジトリを作ることの方が邪道。
これも初耳です。。
う～む、単純に自分の勉強不足のようです。
もっと勉強してみます。
参考になりました。ありがとうございました。
bareの話題ついでに聞きたいんだけど、
>>299 push先が変なのをチェックアウトしてたりdirtyなワーキングディレクトリになってると
pushが通らなくなることがあるけどbareだとその心配がない、とかかなあ。
公開用のリポジトリで、そこで作業することはないっていう保証とか約束みたいなもんだと思う。
git-scm.comメンテナから緊急のお願い
Please read: An urgent appeal from git-scm.com maintainer Scott Chacon
http://git-scm.com/appeal Oracleの話が出てたりしてちょっと危機感ありますね。
githubとか儲かってるらしいんだから支援してくれてもよさそうな気がするんだけどなぁ。
git-scm.comってRailsだったんだ
他のプロジェクトで開発されているソースを取り込んで
自分のプログラムを管理する、つまり
http://progit.org/book/ja/ch6-6.html みたいなことを行いたいと考えています。
上のURL先のように直接rackのリポジトリをsubmodule化すると
rackに対して自分用の改変が行えない(文中にある「公開サーバにプッシュ」が行えない)
と思うのですが、実際にはどのようにすべきなのでしょうか？
305 ：
301 ：2010/12/18(土) 18:58:54
慣れてるなら SCM 的に使いやすいし、ページキャッシュをきちんと使うとかプ
railsが重いっていつの時代だ？
すげーメモリ食うよ
もともと静的ページいくつかで済んでたのをわざわざRails。
Railsは「重い」よ
>>309 # Donations made will actually go to the Git project under the
# Software Freedom Conservancy.
まったくだ アセンブラで書いて速度と容量を最適化すべき
Rails(Ruby)が流行りだったんだよ、文句いうな
そこでJRuby
>>314 git-scm.com見てみろよ。PHPである必要すらないだろ。。。
チャリンコで済むようなところにわざわざレーシングカーみたいなの持ってきて
ガス代足りないからカンパしてくれって言ってるようなもん。
流行ってるからとかいう話じゃない。
経験上だけどpassenger使わなければRailsはそんな重くない。
freetypeのgitリポジトリにつながらない 何で
319 ：
304 ：2010/12/20(月) 01:03:40
>>305 ありがとうございます。
やっぱりリポジトリは2つ必要になるんですね…
>>316 いやいやいやいや、
寄付してくれれてのはクリスマス限定のジョークのつもりだったんだってば。
寄付先は自分じゃないし、こっそり This page is a parody. とか書いてあるぞ。
>>320 なるほど、最近のWikipediaの寄付アピールのパロディなのか。
だいたいまだクリスマスじゃないし、笑えないし、公開後すぐ隠したりでグダグダすぎる。
せめてエイプリルフールにしろっての。
>>319 submoduleを使う場合はリポジトリを入れ子にして使うことになるので
両方公開するとしたら別々になるね。
サブツリーマージって方法もあるけど、、、こっちも分かりにくいけど、
submoduleよりはマシのような気がしないでもないかなぁ。
騙された人は必死にならず「あー騙されたぜ、はっはっは」と言えるくらいの
せやな
笑えないジョークだから半日で消したんだよ。
もう一度同じこと書いてやろうか？
せやなｗｗｗ
同じこと書くのはやめろ。ちゃんと自分の意見を書いてみろ。
オレの意見:
>>301 あなた本気で言っているなら相当頭悪いですよw
一番前まで戻るなよw
オレの意見:
自分のsrcディレクトリ ~/src に、他人のコードが便利そうだから
ごめんpullじゃなくてcloneだった
pullとfetchとcloneの違いはなんなんでしょうか
漢は黙って git init -> git fetch
git svn cloneで途中のリビジョンから複製したら
svnからcloneした履歴はマージしないほうがいいけどね
>>340 え？・・・ああ、svnリポジトリの方は大丈だ夫
読み取りだけでdcommitはしない（出来ない）から。
問題はpushしたgitリポジトリの方だ・・・
またリモートのリポジトリ、作りなおさなきゃ
>>341 よくわからないが、同じツリーのコミットを見つけてマージしちゃうってのはどう？
一度マージしちゃえば共通祖先が出来る。まあヘンテコな履歴になるけどね。
svnの安定版ブランチからgitのブランチを作って、
それをpushしてソースコードを共有していたんだけど
svnのtrunkからの変更を取り込みたくなって、(gitのブランチで)マージを実行したら
全てのファイルがConflictして、共通祖先が無いことに気づいた
>>342 安定版ブランチだけ孤立している状態なんだけど、解決方法あるのかな・・・
>>343 そういうことか。。。キツいね。
svnのほうはmerge-trackingでマージしてるんだろうね。
svnのほうで、安定版ブランチとtrunkの足並みが揃ってるところがあったら
Gitのほうでもそこからフォークしたことにしてやればけっこうコンフリクト減ると思うけど、
そうでなければ地道にcherry-pickして履歴作ってみたり、とかかなぁ。
git-svnがmerge-trackingをサポート、、、するわけないよなぁ。
ちょっと質問いいでしょうか
途中で送信してしまった・・・・
> バージョンアップの度にリリースされたファイルの変化に追従していくうちに、変化を追うのが面倒になってしまいました。
変化を追わないのならただのバックアップだよな…？
>>345 > とある既存の(特に公開リポジトリはなしの)ソフトやソース
これを、素直にリポジトリとして作成する
んで、そこからcloneしてmy_repoブランチを切れば、みんながgithubでやってるような形になるんじゃないかと？
違いは、そのオリジナルのリポジトリを更新するのが、オリジナル開発者か自分かの違い、ってだけで。
でも、今あるmy_repoの履歴も捨てたくないから、この new_my_repo にmy_repoをマージできるか、ってことかな
どうなんだろ
>>348 世代間バックアップくらいの気持ちで最初は使ってました。
gitは実開発でも使っているので、せっかくだし他の用途にも使ってみようかと。
>>349 前半までは理解しています。
> でも、今あるmy_repoの履歴も捨てたくないから、この new_my_repo にmy_repoをマージできるか、ってことかな
問題はここなんです。
実際の開発でもルート(というのかわからないですが。最初のコミット？)がことなる同じプロジェクトをどう扱うか？
ということをたまに迷います。
極論を言えば、手動cherrypickというか今のmy_repoの各コミットをパッチに吐いてnew_my_repoにとりこめばいいわけですし、
もしくは逆にmy_repoじゃない別途管理している既存のソフトの方で
>>347 さんのように差分とって
よければパッチはいて、my_repoに取り込めばいいわけですし
人によってはログや履歴を捨てることを躊躇しない人も今までいました。
しかし個人的な感覚としてそれらはちょっと気持ち悪かったのでシステムで解決できるもっといい方法がないかと思いまして
351 ：
デフォルトの名無しさん ：2011/01/02(日) 17:06:11
git 自体のバージョンが違う、複数のマシンで
バージョン違うことによる不都合って「git log --onelineで見てみて」「エラー出ました！」
353 ：
デフォルトの名無しさん ：2011/01/02(日) 23:31:13
git rebase -i では操作対象コミットの中で最古のものより1つ古いコミットを
root commitに触手を伸ばそうとしている勇者であることは理解できた。
rm -rf .git/; git init; git add .; git commit -m "first commit";
gitってcloneするときにリモートリポジトリもやっぱり全部もってきてる？
$ git rebase -i 最古のコミット
TortoiseGit の日本語化ってできないの
git svnで、ブランチとして扱うディレクトリって
362 ：
361 ：2011/01/11(火) 01:28:21
こんなふうにすれば、出来るみたい
>>360 1.3.2.0向けのはあるけど、開発止まってる
だから自分で言語パックを作ろうとしたのだけれども・・・
入れてみてもコンテキストメニュー以外が全て英語のままだ、なんでだろう
cvsのexportみたいなことって、
365 ：
デフォルトの名無しさん ：2011/01/17(月) 22:17:06
管理情報なしの状態が欲しいならcloneから.gitまるごと消すだけ。
しかしコミット中に今はなきラージオブジェクトがある場合なんか、
367 ：
デフォルトの名無しさん ：2011/01/18(火) 08:46:33
git archiveはデフォルトでtarアーカイブを標準出力に吐き出すので、
上流が git-svn rebase (ただしリードオンリー)してて
直接dcommitするなら、上流はsvnってことになるんじゃない？
>>350 cd new_my_repo
git remote add my_repo ../my_repo
git pull my_repo master
日本語で書いたログメッセージはちゃんとUTF-8で保存されてんの？
UTF-8で書けばな
あるブランチのコミットが別のブランチに全部取り込まれてるか簡単に確認する方法
>>373 git cherry A B
何も出てこなければBのコミットは全てAに入っている
マージしてもプッシュしなきゃよか。
masterがメインで走ってて、安定版をFastForwardでstableブランチにmergeしていってるよくある
git tag
382 ：
380 ：2011/02/01(火) 17:27:50
それが tag のふられてない既存リポジトリなんですよ
>>380 リアルタイムで追いかけて merge とか cherry-pick があったときに tag とか branch でくさび入れるがよろし!
tagって任意のhashにつけられるんじゃなかったっけ？
いつの間にかTortoiseGitが1.6.3.0にバージョンアップしてた
386 ：
380 ：2011/02/02(水) 09:36:52
具体的にいうとx264のgitリポジトリなんだけどね
masterがどんどん走ってて、ここまでならstable!ってポリシーで行ってるの
はいいけど、１個前２個前のstableをcoしたい。ってのができなくて。
committer が
>>383 の言うように "stable:r1875" みたいなtag打ってくれりゃいいんですけどね(´・ω・｀)
どうにもリアルタイムで追いかけてstableなポイントをメモしとかないとダメっぽいですね。
ありがとうございました。
git-svn で元リポジトリの構造が svn/trunk だったのから svn/proj/trunk みたいに
同じような状況で、.git/config だけ書き換えたら大丈夫だろうと思って
>>388 ﾅｶｰﾏ
なんか git svn relocate svn/trunk svn/proj/trunk みたいなのがあるんじゃないかと
思って調べても全然見つからないのよね。
それは git svn が svn switch --relocate をちゃんとしてくれないってこと？
git svn はclone元のsvnリポジトリの構造変化に追従してくれないんじゃない？ってこと。
いや、svnだってcheckout元のsvnリポジトリの構造変化には追従しないよ。
>>392 試してみた。
>いや、svnだってcheckout元のsvnリポジトリの構造変化には追従しないよ。
あらホント。move を追跡してくれるものと思い込んでた。
で、git svn switch は git svn switch 自体が無いみたいですね。
やりかた見つけた＆試してOKだった。
git-svn - switch to a different a svn url - theAdmin.org - Redmine Development by the Redmine Guy, Eric Davis
ttp://theadmin.org/articles/2008/09/30/git-svn-switch-to-a-different-a-svn-url/ 1. .git/config の中の URL を新しい URL に書き換える
2. git svn fetch
3. 1.で書き換えたURLを元に戻す(svn/hoge/proj -> svn/hoge)
4. git svn rebase -l
5. 再び 1. をする。書き換える (svn/hoge -> svn/hoge/proj)
6. git svn rebase がちゃんと動くよ！
条件：svn リポジトリの構造変化 commit (move の commit) の後にファイルの内容変更など、
別の commit が走ってること。(上の例だと svn/hoge/proj/a の変更commitが入ってる、など)
構造変化 commit の直後だと git svn が変化検出できないっぽい。
なんというバッドノウハウ
そのうち git svn switch が実装されると信じて
TortoiseGitでプロジェクトの管理を行っていますが、
質問です。
aliasで!shとか使えば？
>>398 その設定だと、コミットログが化け化けで入っていないか？
コンソールでしか作業をしないのなら、ロケールと端末をEUC-JPに変えるという発想は？
LANGだけでロケール変わらないか？
漏れならソースコードをUTF-8にするの一択
402 ：
398 ：2011/02/09(水) 21:38:07
>>399 私にレスをくださったんでしょうか?
そうだとしたら申し訳ないんですが、
おっしゃってる意味が理解できませんでしたorz
>>400 > その設定だと、コミットログが化け化けで入っていないか？
設定をしないと、git logしたときに化けていました。
ログ入力に使っているエディタ(emacs)のデフォルトエンコーディングはeuc-jpにしてあるので、
コミットログ自体はeuc-jpでgitのリポジトリに格納されるのかな?と思っています。
・・・が、
そうだとすると、
logoutputencodingをutf-8に設定する
=> gitがコミットログをutf-8に変換してから出力してくれている
=> だから文字化けせずに読めた
・・・ということになってしまいますね。
別にlogoutputencodingの設定通りに変換してから出力してくれるわけではないですよね?
> コンソールでしか作業をしないのなら、ロケールと端末をEUC-JPに変えるという発想は？
> LANGだけでロケール変わらないか？
以前は.bashrcにexport LANG=ja_JP.EUC-JPなどと書いていたはずなんですが、
どういうわけだったか忘れましたが、(←アホ)
何か理由があってlocaleはシステムデフォルトにしたという経緯があります。
自宅の環境ではないので、明日、もういちどそのあたりを確認してみようと思います。
404 ：
398 ：2011/02/09(水) 22:00:16
>>401 > 漏れならソースコードをUTF-8にするの一択
自宅ではそうします！
406 ：
398 ：2011/02/09(水) 22:04:50
>>403 読んでみます！
ありがとうございます。
>>405 いろいろ情報ありがとうございます。
そちらも読ませていただきます！
重要な１行があった
最近発見した方法
409 ：
398 ：2011/02/10(木) 23:32:06
>>398 ですが、
アドバイスもらったこと中心に
今日3時間くらいかけて色々見てきました。
情報をいただいたおかげで、
なんか進展した気がします。
ありがとうございました。
###シェルで「export LANG=ja_JP.eucJP」しておく方法###
システムの標準がUTF-8なせいか、
基本的なコマンド類が日本語としてUTF-8のメッセージしか吐かないため、
「export LANG=ja_JP.eucJP」はしないようにしていたんでした。
また、LANGをja_JP.eucJPにしてみても、
肝心のgitの出力は化けたままでした。
###gitattributesのdiff.textconvを使う方法###
gitのv1.7.4で、
git diffの出力について、
この方法でうまく行きました。
ただし、git add -pのときの出力は化けたままでした。
textconvがどのバージョンから使えるようになったの理解しておらず、
いちばんハマりました。
v1.6.0で試す→textconvをまったく介さない模様
v1.6.5で試す→textconvに指定したコマンドにオプションを直接指定できない(nkf -wの「-w」のようなオプションを指定できない)
v1.7.4で試す→うまくいく
410 ：
398 ：2011/02/10(木) 23:41:08
あとは、git add -pしたときに、
windowsすげー
>>408 の方法は、現時点では git-diff に対するフィルタなので git add -p には
何の影響も及ぼさないはず。(要望はあるみたいだが)
自分があまり使わないから気にしてなかった。
自分の設定では、今のところこんな感じにしてる。
.gitattributes
*.xxx diff=nkf blame=nkf show=nkf
~/.gitconfig
[diff "nkf"]
textconv = "nkf -w"
[blame "nkf"]
textconv = "nkf -w"
[show "nkf"]
textconv = "nkf -w"
このスレッドは天才チンパンジー「アイちゃん」が
どうして、京都大学霊長類研究所は、アイちゃんの、
これが、コピペにマジレスの実物か
何でbzr貼るん？
GitGitにしてやんよ！
うむ、InternalServerError出たからマジで驚いたｗ
>>424 > Gitユーザは、リベースの難しさや、多くのBazaarユーザのやり方に対する非難めいた態度にイライラするかもしれません。 Bazaarでは、コミットは「重たく」、ブランチもとても「重たい」ものです。
そこ翻訳ちょっとへんだよな
> git users will also likely be disconcerted by the difficulty of rebasing, and by the very disapproving attitude of many Bazaar users toward the practice. Commits are "heavier", and branches are very "heavy" in Bazaar.
> Gitユーザは、リベースの難しさ、そしてやり方についての多くのBazaarユーザのとても非難めいた態度に、
430 ：
デフォルトの名無しさん ：2011/02/19(土) 13:11:26
GITはいつになったら日本語ファイル名に対応するんだ？
ユーザの多くがプログラマーなら、そんなもの必要だとは思ってない。
>>430 Mercurial追い出されて今度はこっちですか？
具体的にどこがどう対応していないのですか？
433 ：
デフォルトの名無しさん ：2011/02/19(土) 15:17:57
GITでは、WindowsとLinuxの相互運用で日本語ファイル名が文字化けする。
「文字化け」という言葉を使っている時点で馬鹿丸出し
「実用に使えない」とか日本語不自由な人間が日本語ファイル名なんか気にすんなよ
GitもTortoiseGitも使ってるけど
437 ：
デフォルトの名無しさん ：2011/02/19(土) 16:44:00
機能面で反論できないところを見ると、やはりGITが糞ソフトであることは間違いないようだ。
Gitの時代になっても日本人は英語コミュニティに及び腰、だろ?
2010年代にもなってWindowsがCP932なのがアホ
TortoiseGitで日本語ファイル名を使う需要が本当にあるのか。
441 ：
デフォルトの名無しさん ：2011/02/19(土) 17:07:01
メジャーなOSで普通にファイル名に利用出来る文字で文字化けが起こるソフトが糞。
どんな文字でもどんな長さでもファイル名に使えると思ってる世代は幸せだね。
git config --global core.quotepath false を知らないアホがいると聞いて
quotepathやログを含め、Gitの多言語対応はしっかりしている。
446 ：
デフォルトの名無しさん ：2011/02/19(土) 19:13:36
GITはクロスプラットフォームで文字化けが発生してしまうから使いものにならない。
>>446 じゃあそれでいいです
はいほかの方どうぞ
文字化けの話題はもう
>>443 で解決してる
次の話題どうぞ
>>449 はクロスプラットフォームでの問題を理解出来ないバカ。
cygwinも使えない馬鹿がいると聞いて
452 ：
デフォルトの名無しさん ：2011/02/19(土) 19:38:53
cygwinを使わないと日本語環境でまともに利用できないバカなソフトがあると聞いて
UIがcygwin環境に縛られる時点で、Windowsソフトとして終わってる。
そもそもWindowsソフトじゃないし。
455 ：
デフォルトの名無しさん ：2011/02/19(土) 19:44:43.88
やっぱりGITはWindows未対応なんだ。
どっちかっつーといつまでもUTF8ロケール用意できないWindowsが終わってるのでは
457 ：
デフォルトの名無しさん ：2011/02/19(土) 19:48:50.21
Windows批判はスレ違いです。
え、Windows って GIT 未対応なの?
クスクス…いまどきGitが使えない環境なんて遅れてるｗ
460 ：
デフォルトの名無しさん ：2011/02/19(土) 19:54:36.33
//／／／／／／, ''" ヽﾐ川川
えっ、日本語ってGitに対応してないのｗｗｗｗ
>>461 EUC-JPもUTF-8も対応しています。cygwinでも。
開発陣を無能だと思うんなら有能な君がパッチを送ればいいじゃないか
>>463 当然ISO-2022-JPも対応しています。cygwinは分からん。
Windowsで使えないなんて信じられないニダ！
468 ：
デフォルトの名無しさん ：2011/02/19(土) 21:37:46.55
単にGITが日本では実用にならない糞ソフトってことだよ。謝罪も賠償も必要ない。
と言うことにしたいのですね？
>>468 GITとやらが糞ソフトならLINUXは何ソフト？
471 ：
デフォルトの名無しさん ：2011/02/19(土) 22:35:24.29
比較的有用なOS
git grep って
473 ：
デフォルトの名無しさん ：2011/02/20(日) 01:09:11.88
git help grep
475 ：
デフォルトの名無しさん ：2011/02/20(日) 13:10:54.21
比較的有用なOS
比較対象は秘密だけどな
>>476 Winが公式に認める比較対象は、旧バージョンのWinのみ。
479 ：
デフォルトの名無しさん ：2011/02/21(月) 17:05:32.87
共有リポジトリサーバで、ブランチ毎に clone/push/pull するにはどうすればいいんですかね？
んなこたーない。指定できるよ。
もうちょっとヒントだしてあげてもいいと思うけど。
>>479 cloneはブランチ毎にはできないはず。git clone URL でぜんぶまとめてとってくる。
pushとpullはブランチ毎にできる。
git co -b dev origin/dev
git commit
git push origin dev
まちがってたらごめん。自分も勉強中なんだ。
ありがとうございます。
自分も似たようなことしたくて調べてみたら
サブモジュールはどうしても必要に迫られない限り、やりたくないなぁ。
サブモジュールがいやならrepoを使えばいいじゃない。
>>485 おー、これ良さそうだね！ 教えてくれてありがとう！
オブジェクトは共用(bareでも可)で、複数のディレクトリで各ブランチをチェックアウトしたままにしておきたいんだがどうすればいい?
>>487 オブジェクト共用って、ディスクスペースを節約したいってこと？
cloneのオプションでハードリンクにすることも出来るけど、そういうことではなく？
>>488 Unixだと問題ないのかな? win だと無理?
git gc のことを考えなければ、単純に git を騙して共用させられればいけるような気もするが…
git-new-workdir
msysGit-netinstall-1.7.4-preview20110204.exeでGitをインストールしようとしたら
492 ：
デフォルトの名無しさん ：2011/02/26(土) 15:34:40.78
質問させてください。
493 ：
492 ：2011/02/26(土) 15:38:21.40
俺様がよくやる方法みたいな情報も大歓迎です｡
>>492 ほんの軽い差分ならstash、いくつかのコミットになるなら俺ブランチでrebase、
って感じかな。
495 ：
デフォルトの名無しさん ：2011/02/26(土) 15:59:29.46
>>494 早速のレスありがとうございます！
>いくつかのコミットになるなら
どんどん進化していくような俺コードだとstashは不適切という訳ですね｡
φ(..)メモメモ
>>495 どっかの公開repoに俺修正で追っかけてくのは、Git使うと基本作業みたいなものなので、
mergeして追随するパターン、rebaseするパターン、とりあえずstash、
それぞれじっくりやってみたらいいと思うよ。
>496
>492
>>492 俺コードをguiltで管理する方法もある
>>498 >>499 レスありがとうございます！
> 2以外はだいたい一緒
あ、1,2,3にしたつもりが1,1,2になってますね>_<
> 俺コードをguiltで管理
そんな方法もあるんですね｡
ざっと調べてみましたが、stashと異なるのは､
・gitのコミットとして管理される
・適用したquiltを元に戻すのが簡単
といったところでしょうか｡
git svn fetchでRefspec glob conflictってのがたくさん出ますが、どういう意味なんでしょう？
>>501 何かおかしいみたいだけど、どういう設定でgit-svn initしたのかな？
質問です。gitはじめて触ってます。
環境: OSX 10.6.6, git 1.7.0
http://linux.yyz.us/git-howto.html#download_first_time このあたりの手順に従ってLinux kernelをcloneしてみました。
それから、clone直後のワーキングディレクトリのトップで
git diff とすると、まだ何も編集していないのに差分がゾロゾロ
出てきます。
この挙動は正しくない気がするのですが、他の方の環境でも同じ
ことになるでしょうか？
ちなみにファイル名だけですとこんな感じになります。
linux-2.6$ git diff --name-only
include/linux/netfilter/xt_CONNMARK.h
include/linux/netfilter/xt_DSCP.h
include/linux/netfilter/xt_MARK.h
include/linux/netfilter/xt_RATEEST.h
include/linux/netfilter/xt_TCPMSS.h
include/linux/netfilter_ipv4/ipt_ECN.h
include/linux/netfilter_ipv4/ipt_TTL.h
include/linux/netfilter_ipv6/ip6t_HL.h
net/ipv4/netfilter/ipt_ECN.c
net/netfilter/xt_DSCP.c
net/netfilter/xt_HL.c
net/netfilter/xt_RATEEST.c
net/netfilter/xt_TCPMSS.c
>>503 LinuxとOSXで試して分かった。
同じディレクトリに大文字、小文字だけ違うファイルがあるんだけど
OSXはそれを同じファイルとして扱うから先に作られたファイルが上書きされるんだ。
505 ：
デフォルトの名無しさん ：2011/03/07(月) 09:16:41.48
となると、OSX的にはcase sensitiveなディスクイメージを作って、それを
>>504 俺もそれバグかと思った。checkoutでも怒られることあるよ
ところで大文字小文字の違いだけでファイルを分けるのはどうなんだろう
>>507 微妙な違いだと目視で間違えそうだし、HFSみたいなファイルシステムのことを考えるなら
あまりよくないだろうね。
509 ：
デフォルトの名無しさん ：2011/03/07(月) 11:15:23.38
カビの生えたソフトのtar玉(.tar.Zだったりする)の中に
ああ
呼ばれる名前で挙動が変わる？ Gitはそうだよｗ
え・・・なんで一人でテンション上がってんのこの人
すまん、寝てないんだ
514 ：
501 ：2011/03/07(月) 22:59:09.31
>>502 そのリビジョンでまだ存在しないブランチを指定してfetchすると、固まって進まなった事があったので、
ブランチの追加されるリビジョンでconfigを変えることを繰り返し、現在こんな感じです
[svn-remote "svn"]
url =
https://irrlicht.svn.sourceforge.net/svnroot/irrlicht fetch = trunk:refs/remotes/trunk
branches = branches/releases/*:refs/remotes/*
branches = branches/{SkinnedMesh}:refs/remotes/*
branches = branches/{ogl-es}:refs/remotes/*
branches = {vendor}:refs/remotes/vendor/*
tags = tags/*:refs/remotes/tags/*
OSはwindows7
gitマジおぬぬめ
hgがいいんでね？
間を取って、hgitおすすめ。
LLじゃなくCで実装されてるなら何でも良いよん
>>515 日本語のファイル名をつけたいなら、日本語WindowsでGitは化けるらしいよ。
UTF-8に対応したCygwinとかいうのなら、大丈夫らしいけど。
521 ：
515 ：2011/03/08(火) 16:56:55.40
みなさんありがとうございます。
522 ：
503 ：2011/03/13(日) 18:59:49.67
遅くなりましたが
>>503 です。
皆さんの言う通りファイルシステムの違いによるものでした。
ディスクイメージを作ってそこにcase-sensitiveなファイルシステムを
作ってみたところ、正しくチェックアウトできました。
ありがとうございます。
会社はSubversionなんだけど、
別に前revision変換しなくてもよくね？
>>524 >>523 ですが、会社行ったら
Out of memory!
になって死んでました。
とりあえずブランチだのタグだのは諦めて、
自分の担当パートだけ、
git cloneしてみました。
これであとはgitの使い方に慣れて行けば、
あれやこれやの変更をパッチ形式で持ち続ける必要なくなるかな。
svnのブランチやら、他のツリーへのマージは
結局パッチにしてそれをあててからリリースになるんだろうけど。
>>525 git svn clone だよね？
git svn dcommit で Subversion 側にコミットもできるよ。
ああごめん。
>>526-
>>527 >>525 です。
自分の担当パートだけ
trunkからgit svn cloneしました。
以下のようなSubversionのリポジトリから、
git svn clone repo/trunk/apps/担当パート
という感じです。
これで、
trunkの担当パート部分については、
git svn dcommitでうまくコミットしていけると思ってます。
`-- repo
|-- branches
| |-- branch_A
| |-- branch_B
| `-- branch_C
|-- tags
| |-- tag_A
| |-- tag_B
| `-- tag_C
`-- trunk
`-- apps
|-- A
|-- B
|-- 担当パート
`-- C
～
>>528 のつづきです～
・・・で、担当パートの変更は、
ブランチにもチェックインしないといけないんですが、
そういうときに、本当なら
git svn clone repo
してあれば、もっとうまいことできるってことなんですよね？
実際のところ、
（branchでは無く何故か）repoをコピーして作ったリポジトリもあったりして
そっちにもチェックインしないといけないので、
どっちにしてもパッチは使わざるを得ない感じです。
しばらく「trunk以外にはパッチ」対応しようと思いますが、
これじゃせっかくのコミットログが活かせなくて、めんどくさいですよね・・・
Gitはうまいことやってくれてるのになあorz
msysgitでgit svn cloneしたリポジトリで、Linux上でgit svn fetchしたら
で？
$ git init
ブランチ切る元がないんだから当たり前に見えるな
幹がなけりゃ枝も生えん
え、でもファイルがないとコミットできないんですよ(´･ω･`)
つまり、空のディレクトリで git init しましたってことなん？
>>535 ブランチの名前は後から自由に変えられる
echo "hoge" > hoge.txt
>>535 Gitでは ブランチ＝コミットに対する別名 なので、
ブランチを"切る" というような動詞から連想するようなことは起こっていない。
どうしてもやりたいなら、こうかな
git init
git symbolic-ref HEAD refs/heads/dev-branch
特定のファイルの追加や削除の追跡をしたいのですがよい方法はないですか？
普通にi git log filename じゃダメなん？
>>536 そうですね空のままは変ですね
>>537-539 あーなるほど
ブランチやタグはコミットに名前をつけているんだということをわかったつもりだったのに理解していませんでした
コミットした後からでこちらの想定の使い方的に問題ないようでした
ありがとうございました
現在のファイルにおいて、
>>543 俺もそういう時 git log -p してた。何か方法があるなら知りたいな。
>>543 git log -S"〈文字列〉"
で、〈文字列〉が追加または削除された履歴を確認できる
そんな方法があるんですね！
>>545 うわこれめっちゃ便利だ！！！
ありがとう！！！
githubでpullリクエストもらった時、複数のコミットが含まれてるのの１つだけマージするとか可能でしょうか？
>>548 途中までOKなのなら その位置を指定してマージでいけるけど、歯抜けだと cherry-pick ですな。
ただし、つまみ食いしても問題のないパッチシリーズじゃないと、おかしなことに。
もしpullリクエストしてる側がまるごと取り込んで欲しいと考えてるようであれば、
まるごとのマージは出来ない理由を示して、惜しいのであれば一部修正してもらったら
良いのではないでしょうか。そしたらまるっとマージしてお互いにハッピー。
>>549 ありがとうございます、途中までは採用したいので、位置指定するマージのやりかたを調べてみます。
全ブランチにmasterの変更をマージする方法はありますか?
rebase？
>>551 hookかな
なんにしてもコンフリクトする可能性は考えないといけないが
>>551 です。
ありがとうございました。
たぶん私がまずやるべきはrebaseですね。
それをhookで自動化できるかも...
という感じでしょうか。
ちょっと調べてみます。
ありがとうございました。
git-now！
git nowってどの辺が便利なん？
そんなコマンドないよ
stash知らないのか
stashはうっかりstash clearとかしちゃうと大変だからコミットにしてるとかかな
マジでログメッセージ入れる意味すら無いのなら commit -m wip とかでいい。
いいんじゃね？リズムよく
俺もstash使わずたいていwip branchだな。
git コマンド関係ない質問
>>564 基本的には、個々の内容が妥当だという自信があるなら全て出すべき
たとえ自分の issue で 2 ページ埋まってもね
あれは known bugs な広報欄の役目も果たしてるから、不具合情報は共有されるべき
ただ
「issue は 0 にしてから次バージョン出すよぉ」
という潔癖さんが開発に混じってると問題はややこしく…ｗ
出すのは勝手(むしろ歓迎)だが、出し方に気を付けないと、シカトされるか
たとえ嫌われても、差分コードを公開さえしてれば「いつのまにか」直ってることはよくある
コード書くことで別の方法が思いついたりくっついたり分かれたり本質でないことに気づいたりするもんなので、
BLってブラックリストのことか。普通にボーイズラブかと思ったよ。
ボーイズラブでも普通に意味は通るな。
てっきり次にこういうコマンド打つとこういう結果になるよって suggest してくれる機能かと思ってた > git now
git-emacs で直接コミットメッセージ開き直して git commit -a --amend してくれる機能とかないの
GNU EmacsはBazaarで開発されています。
>>574 とは言えemacs向けのbzrに特化したelが有る訳でも無し。
GitHubで、いくつかプルリクエストしてメインに受け入れられました
プルとプッシュがよくわかりません。
579 ：
デフォルトの名無しさん ：2011/04/20(水) 14:42:18.38
先輩方、どうか助けてください
WindowsにGitを入れました
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/gittutorial.htmlを元にGitを覚えています デスクトップのGit Bashアイコンを起動して
cd \code\java\testに移動して
git initをして
git add .をやったあとに
git commitをしたら
エディタが起動して
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Committer: unknown <ユーザー名@.(none)>
#
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: Test.class
# new file: Test.java
#
って表示されました。
wikiのコミットコマンドを実行すると、コミットメッセージの入力が求められます。 その後、プロジェクトの最初のバージョンが git に格納させます。」ってところでつまづいてます。
ここからどうしたらよいのか判りません
どなたかお力添えをお願いいたします
viの使い方覚えましょう
>>578 カタカナだとわけわかめになる
pull は英単語
push も英単語
582 ：
デフォルトの名無しさん ：2011/04/20(水) 15:09:30.06
>>577 orgissue12みたいなブランチ切ってpull requestするようにすれば後から見てもわかりやすい。
上流にマージされたなら消しても問題ないし残してても問題ないし好きにすればいいと思う。
583 ：
デフォルトの名無しさん ：2011/04/20(水) 15:13:18.79
>>580 ありがとうございます！！！！これでコミットできました！
pull は（サーバから）引っ張り込むんだよ
586 ：
デフォルトの名無しさん ：2011/04/20(水) 15:44:00.32
バージョン管理初心者はGitとSVNどっちがお勧めですか？
さすが兄者ｗ
>>586 ＧｉｔとSVNという選択の仕方がすでに間違っている気がするｗ
Ｇｉｔと何かというならMercurialとかBazaarじゃね。
gitとsvnの間で悩む時点で、分散かどうかなんてどうでもいいってことだろう。
ひとまずDropbox使ってソースの置かれているディレクトリを対象に含めると良い。
592 ：
デフォルトの名無しさん ：2011/04/20(水) 16:48:36.16
用途を書いておきます
ならsvnじゃね？
>>592 その用途なら、俺もDropbox進めるわ。
1ファイルのサイズがでかいというなら外付けHDDと差分バックアップソフトかな。
どうしてもこの系統のソフトが使いたいならSubversion（winならTortiseSVN）で良いんじゃね。
Dropboxって無料版だと30日で消されるんだって
話の途中で申し訳ないが質問していいっすか？
>>596 いや、普通に毎日ログインするだろｗ
てかおれの1年以上ほかしてたけど内容のこってたわ。
>>597 1. git rebase --continue
2. git checkout
3. git rebase (-i)
マジにネタレス。
st(atus)だな
git remote update --prune もよく使う。
603 ：
デフォルトの名無しさん ：2011/04/20(水) 22:23:24.15
たぶんgit grepとgit log foo/bar.txt
>>604 git pushのmanページに詳しく書いてあるよ。
なぜpushで新規作成する時だけrefs/headsとフルで書かないといけないかというと、
フルで指定しないとどこに作っていいか曖昧だからだろう。まあ普通は refs/heads/
ですよね、ってことではあるけど、そうじゃない場合もありうるので。
>>561 このwipってどういう意味なんだ
ぐぐったら一時的な(gitで言えばstash的な)作業やブランチ、コミットに使われているみたいだけど
ジャーゴン？
607 ：
606 ：2011/04/20(水) 23:45:56.10
ふつうに英語の略語だったわ
cloneはリポジトリ作成時くらいだからよく使うもんでもないだろう
611 ：
604 ：2011/04/21(木) 01:32:36.87
>>605 ありがとうございます。 では、これを応用して、既存のどこかのコミットにtagを打って
そこからブランチを切るというのをリモートに対して行うというのはこういう感じが
正当でしょうか？
$ git tag 1.3.0 <hash> # 1.3.0 はここと決める
$ git push --tags
$ git push origin 1.3.0:refs/heads/1.3-maint # 1.3.0を頭に1.3.* の保守ブランチを作る。
git svnで、SVNレポジトリをcloneして使ってるんだけど、
>>612 master は svn-rebase & svn-dcommit 専用ブランチとして割りきって
俺作業用ブランチの上であれこれするのがよい。
俺の場合、dcommit する際には cherry-pick が基本だな。
git-svn と暮らすには、rebase 基本のワークフローにするのがベターと思う。
>>609 git clone を cvs checkout と同じ用途で使うバカもいるみたいだぞ。
これが一番確実、とか意味不明なこと言って。
えﾞ、俺バカだ。
>>613 gitはリモートのファイルにオレオレパッチやオレオレ修正あてたまま、
公式のリリースに追従していくとが楽でいいよね
これだけでもsvnから移行したかいがあった
svnでもできるかもしれないし、gitというか分散型の特徴なのかもしれないけれど
地震に備えてソースコードをバックアップして置きたいのですが
DropBox等につっこむとか
>>618 mercurialに変換してbitbucket
>>611 正当というのがどういうのか分からないけど、
ローカルにタグ、リモートにブランチが欲しいなら、
そういう感じで良いんじゃないですかね。
リモートのHEADをmasterから動かすのは、Gitコマンドだけじゃ出来ないっぽい。
GitHubはWebから出来るようになってるけれど。
>>612 stashを使うというのも手ですね
>>623 あの"Private"はURLが分かれば誰でもアクセスできるよ
バージョン管理というものはいまいちよく分かりません
>>626 そもそも「なぜバージョンを管理する必要があるののか」というのを先に学んだ方が良いかも。
必要に迫られてバージョン管理しようと思った人は「なぜ」が分かるから、一つ一つの作業の
意味を掴みやすい。
漠然と始めたりすると「なぜ」必要なのか分からないから、リポジトリ・コミット・履歴管理と
言った言葉で、バージョン管理ソフトが何をしようとしているのか理解できないのかも。
atwikiの法は難しくて挫折しました（ぇ
git branch test
631 ：
デフォルトの名無しさん ：2011/04/24(日) 17:21:11.86
それはtouch fooしたあとmkdir fooしたら怒られるってくらい理不尽だと思うｗ
/ は git branch のとき内包的関係が見やすいんだよね
/区切りのブランチ名を総括できればうれしいんだが…
>>632 test_vol1が無ければ、これはできるでしょ
test_vol1/foo
test_vol1/bar_baz
>>636 Megauploadにプライベートファイル置いた時並にひでぇｗ
↑個人ストレージのつもりで借りたら丸見えだったでござる
Gitで、マージ時に同じコミットが2回適用される可能性がある場合、どのような挙動なのか教えてください。
>>640 とりあえずやってみようぜ？
rebaseが自動判定してくれるのは知ってるけど、mergeはどうだったっけなぁ。
>>641 Gitはまだ触ったことないんでちょっと試すというわけにはいかないんですが、
マージがどのくらい賢いのかがわかんなくて、すごく賢いようだったら
Gitの勉強をしようかなと思って、その判断をするために質問しました。
>>640 が分かる方いましたらよろしくお願いします。
>>642 ちょっと触るぐらい簡単だろうよ…cherrypickとか知ってるんなら他のVCS使ってるんだろ。
何にもしないでただ教えろって知恵袋かよ。
マジレスするとmergeは3wayマージするだけなので間のコミットとか関係ない。
マージベースがちゃんと取れれば、同じコミットが含まれてたりする場合でも
たいていうまくいく。あまり行が近かったりすると別の意味でconflictになるけど。
dropboxって30日で消えるんですか？
dropbox内のフォルダをgitやらなんやらでバージョン管理すればいいよ
ああ，専ブラで横のタブにDropbox総合スレがあったから見間違えた
ということは常に最新のファイルは消されないってことですね
>>647 一時期、cronで定期的にzipして自分のgmail口座にメールで送るというのを
バックアップとして使ってた。
Git+GAEで管理できたらいいな
>>647 そんな心配していたら、何も使えないだろ。
ローカルのHDDが吹っ飛ぶ可能性だってあるんだぜ。
githubとsvnの違いを説明してください
githubがphpでsvnがperlだ
svnっていうやつはサーバー立てるんですか？
偽きめえなw
はい 教えてください
教えろよボケ
はよ教えろｗ
宣伝成功！！ｗｗｗ
dropboxでコードのバックアップ取っている方に質問です
むしろ、使わないでどうするんだｗ
C:\Users\ユーザー名\Dropboxが出来たけどいまいちよくわかんないし
Gitスレでやることじゃねえだろ
なんでdoropboxスレで聞かないの？
VS2008にgit extentionsつっこんだんだけど、
コミットログを書くときのエンコーディングを統一するか、
リモートのブランチを全部再現することってできませんか？
git fetch --all
書いたあとで思ったが
>>671 git branch は引数を2つ取ることができる(普段は1個)
git branch hoge origin/hoge
とするとリモートにあった hoge が監視下に入る
リモートになにがあったかの情報は git clone した時点で既に手元に来てるので
git branch -a でもして表示しれ
一発ではできない気がするので、適宜使うブランチだけ再現
675 ：
デフォルトの名無しさん ：2011/05/02(月) 10:25:52.47
>>665 Dropboxは場所が固定だが、
SugarSyncみたいな任意のフォルダを同期できるサービスもあるよ。
676 ：
デフォルトの名無しさん ：2011/05/02(月) 14:26:16.02
>>646 >バージョン情報を保ちたいなら，リポジトリ自体をDropbox上に作れという話
これやってるけど無茶苦茶便利。
自分の開発機だと別のマシンでもチェックアウトする必要ないんだもん。
>>676 それって多人数開発でもうまくいくの？
なんだか一人開発が前提のように見えるけど。
publicで共有すればできるだろ
>>677 もちろんDropboxは一人だけですよ。
何のための分散型バージョン管理なんですかっ
dropboxを一人で使うことと分散型に関連性があるのか。
1つのdropboxを多人数で使うのは集中型的手法。
多数のdropboxを使うと言ったって共有する部分は集中型じゃん。
集中しなくてもいいんですよ
なんのスレ
ここは初めてか? ケツの○を抜けよ.
バザアッー！
dropboxでgitを管理する方法を教えてください
馬鹿には無理
しね
何故彼はdropboxでgitを管理しようと思ったのか・・・w
dropboxでgitを管理する上で特有の何かを聞きたいわけでもなさそうだし
>>688 一つずつ学んでいこう
まずはgitの使い方、次にDropboxの使い方を学ぼう
逆でもいい
それから、gitのリポジトリをDropboxで管理する方法が適切かどうか判断したほうがいい
俺ならgitのリポジトリをDropboxには置かないがこれは俺の判断だし
だってさ無料で非公開で管理できるサーバが欲しかったんですよ
>>688 > ここにgitのリポジトリを作ればいいんですか？
まずやってみろよ
> あと、コミットはどこにやればいいのでしょうか？
まずやってみろよ
> dropboxのサイトのほうですか？それともc:\dropbox内のgitのリポジトリに対してですか？
まずやってみろよ
> それと、30日でファイルが消えるってありますが、30日以内にファイルをコミットし続けないといけないのでしょうか？
Dropboxスレで聞けよ
やりたいんですけど壊れたら怖いので聞いてみたのですよ
しね
おじさん、しねって言葉は使っちゃダメですよ
バージョン管理システム動かしたくらいでPCが壊れるわけねーだろ
低脳に居座られてこのスレも大変だなｗ
おまえもな
一昔前の週刊アスキーに
はあ？
>>703 うん、にわかには信じられないだろ？
でも書いてあったんだよマジで…
GitHubのマスコットキャラできたよー＼(＾o＾)／
1 名前：名前書いたら負けかなと思っている。[] 投稿日：2011/05/04(日) 19:44:17.00 ID:jUD92DB10
置時ヤト「ぎっとぎっとにしてやんよ」
2 名前：名前書いたら負けかなと思っている。[] 投稿日：2011/05/04(日) 19:48:15.86 ID:3n/xOSb20
あぶらのってるね
かわいい
3 名前：名前書いたら負けかなと思っている。[] 投稿日：2011/05/04(日) 19:50:22.50 ID:kZN4mp+gO
ぷっしゅ権限ないよよくみて
4 名前：名前書いたら負けかなと思っている。[] 投稿日：2011/05/04(日) 19:51:08.73 ID:le+p2h710
ぎとぎとのギットギット
5 名前：名前書いたら負けかなと思っている。[] 投稿日：2011/05/04(日) 19:52:14.94 ID:UA8r/fIoP
そうなんだためになる
http://kamome.2ch.net/test/read.cgi/river/1302430556/ WinだけどFirefoxってブラウザのくせにインストールするとちゃっかりサービスに登録しちゃうんだよな
えっ
えっ
709 ：
デフォルトの名無しさん ：2011/05/05(木) 00:03:15.61
えっ
知らないなら自分で確認したらどうだ
えっ
えっ
最近このスレも活発になってきましたね！！
715 ：
デフォルトの名無しさん ：2011/05/05(木) 08:43:29.54
えっ
馬鹿の一つ覚え
えっ
718 ：
デフォルトの名無しさん ：2011/05/05(木) 15:15:48.56
えっ
うわ、糞の役にも立たない手抜きソフトしかない(棒
>>705 ダム板はいいとして実質マスコットはoctocatだからな・・・
だから おくときヤト なんでしょ
マスコットはどーもくんだろ
725 ：
デフォルトの名無しさん ：2011/05/08(日) 18:51:02.84
makeするといくつかの実行ファイルができます。
727 ：
デフォルトの名無しさん ：2011/05/08(日) 19:16:04.67
>>726 ファイル名を決め打ちできないこともないのですが、
開発しているうちにいろいろ変わるのです。
たとえば、main_foo, main_bar, main_baz, ... のように。
一方、main.c, main.h, ....などがいろいろあるので、
.gitignore に
main*
!*.c
!*.h
...
のように書けばいいのかな。
これまた随分と保守しづらい開発方法取ってんだねえ・・・ｗ
出力フォルダを別にするとかかなあ
731 ：
679 ：2011/05/09(月) 15:56:41.95
>>680 ネタがちょいと古いけど・・・
Dropboxを多人数で開発するときの共有レポジトリの管理場所にするって話だと
二人で同時に触っていると問題がでる。
だから、Dropboxを複数人で触る場所には出来ない。
多人数で開発する場合は、やはりサーバを立ててそこにpushする開発スタイルに
ならざるを得ないと思っている。
だから、個人の作業を複数マシン(家と会社とモバイルとか)にまたがって
持ち越せたら便利だな、という所で、その持ち越しをDropboxを使ってやったという話なのです。
もちろん、そのスタイルはSubversionのワーキングコピーに対してでも可能だし
VCSの種類にあまり依存しないと思う。
ただ、
>>677 がDropboxを多人数開発の手段として使うという誤解をしているようだったので
それに対して異を唱えておきたかった、というのが
>>679 Dropboxを使えば、一人で開発を始めるときに使い始めて
後でサーバを立てたときもその流れで環境を使い続けられると言うのがいい事かと。
>>731-732 リポジトリだけをDropboxにおくってこと？
これってリポジトリ壊れないのか。
検索したら、壊れるからとTrueCryptに入れてDropboxに入れている人がいた。
ようするに1つのディスクイメージに入れるってことだと思う。Dropboxは1ファイルでも差分同期してくれるから早いらしい。
そりゃリポジトリとDropboxの更新が非同期なんだから、中途半端にsyncしたあと
Dropboxよくわからないけど、手動で完全にSyncできるなら壊れにくくはなるのかな。
git svnで作ったリポジトリでblameしたら
>>736 それってまだコミットされてない行だよ。
git svnがうまくいってないんじゃない？
738 ：
736 ：2011/05/12(木) 22:48:00.13
>>737 作業コピーのファイルは弄っていないです
blameを始めるコミットハッシュを指定すると正常に表示されました
でも、いちいち指定しないといけないのは面倒です・・・
git svnがうまく行っていないとはどういう事でしょうか？
他のgit svnで作ったリポジトリでblameをしてみても、同じような事が起こります
そのリポジトリをgit cloneして、もう1つリポジトリを作っても同じでした
git blame COMMIT_HASH.. -- filename
COMMIT_HASHにHEADって指定したらどうなる？
740 ：
736 ：2011/05/13(金) 21:51:58.64
>>739 同じです・・・
Not Commited Yetの行ばかりになります
>>740 ちゃんとクリーンな状態なの？ git statusしてmodifiedとか出てない？
〇〇というブランチの××というファイルの内容を参照して書きたい、という場合に、うまい表示法はありませんか
>>742 そんなあなたにgitg
いつもおそばにgitg
※ gitkでも可
ブランチ選んでコミット選んでtreeタブをクリックしてディレクトリたどってファイルをクリックするとあら不思議
>>742 git show branch:path
git checkout .
バージョンいくつの話？
うーんと、Ubuntu10.10 だから git 1.7.1 で、…うん、1年前のだな
>>746 カレントディレクトリ「.」にHEADのファイルを再帰的にチェックアウトしろ
ってことだから、当然そうなるもんだと思ってたけど・・・
てかcheckoutってそういうもんじゃないんだっけ
--force があっても良いかもと思わなくもない
>>746 git checkout ''
でも同じようになるね
754 ：
デフォルトの名無しさん ：2011/05/16(月) 00:17:15.24
質問です。
autocrlfあたりが発動して改行コード変わってるんじゃね
そもそも git-chekcout はブランチ名とファイルパスの引数2つなのよ
>>756 1リポジトリに1作業ツリーというのがGitの特徴でもあるからね。
他のVCSみたいにブランチ毎に別ディレクトリにチェックアウトしたりしないから
まずそこで戸惑ってるんでしょ。そこが理解できればgit-checkoutのやり方でも
違和感無いはず。
そもPlumbingのコマンドを複数組み合わせて手間を無くしたのがPorcelainだから、
複数の動作が組み込まれちゃってるのも道理。
git cherry-pick はコミットを「持ってきて」現在のブランチにコミットするが、
git://github.com/user/project.git
>>760 >要はgitが提供する一番ネットワークに負荷がかからない方法でお願いします。
github鯖自体への負荷は問題にしないってか?
>>762 >コマンドでは出来ないってことですか？
Git においてリモートリポジトリを操作するという思想はそもそも存在しない。
github.com の compare でどうにもならないのだったらあきらめて fetch しろ。
>>765 なるほど、「出来ない」のですね。
色々と割り切った考え方の元に作られたツールだと
思ってましたが、そういうのも出来ないのは驚きでした。
使っていたソフトの開発元が svn+trac からgithubに
変わってしまってかなり機能後退と分かりゲンナリです。
普通にDLしてdiffするのが短時間で済みそうなので
これにて。ありがとうございました。
「分散」型バージョン管理システムなのにリモートリポジトリを操作するって発想がよくわからん
そろそろ爆釣宣言が来るか?
github diffでググったら4件目くらいに出てきたよ
クローラ対策のために
https://github.com/ 省略してある。
/mirrors/linux-2.6/compare/v2.6.38-rc1...v2.6.38-rc2.diff
/mirrors/linux-2.6/compare/v2.6.38-rc1...v2.6.38-rc2.patch
できなくもない(てかゲンナリ君の希望には添えるか?)が、
Linux規模になると鯖への負荷も相当なもんだな。いっぺん500喰らっちゃったよ。
>>770 .patchのほうが生のパッチだよね
.diffのほうはそのままだとpatchには食わせられなかったりする
git checkoutって変更したファイルは確認でなかっけ？
わっ確認出ないなあぶねー
コミット前でreflogにもでないし開発中にやったら悶絶するなこれ
パス指定したらそりゃ上書きするでしょう…そういうものだもの
だから git-checkout branch_name は「ブランチ移動コマンド」ではないと何度
>>760 git clone git://github.com/user/project.git
cd project
git diff v0.1 v0.2
mjrs ktkr
i ｉ ｌ l
>>777 > 要はgitが提供する一番ネットワークに負荷がかからない方法で
と思ったが条件はみたいしてるか
都度 clone するヤツは頃してもいいとオモ
TortoiseGitってDebugだと全然ビルド通らない
リリース用じゃないんだろ
Gitは、スゲーむずかしいから、分散VCS初心者は
SIerって。。。
gitの難しさは既存のバージョン管理と管理方法がかなり離れていることが大きい
最近オブジェクトレベル(いわゆる低レ)操作スクリプトに凝っている俺が来ますたよ。
Linusの個人ツールに使いやすさ、分かりやすさを求めるのが間違いです
プログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
>>788 もうLinusは開発に関わってないんだがｗｗ
メンテナはしてないけどパッチはたまに送ってるよ
>>789 x プログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
o Unixプログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
793 ：
414 ：2011/05/20(金) 13:39:30.82
794 ：
790 ：2011/05/20(金) 14:00:55.30
>>793 指摘感謝
ともあれ今やこの程度のコミット頻度であっても
「プログラマ以外には全くもってわかりにくいように」
というLinusの意思が連綿と生き続けているのは凄いねｗ
>>789 GUIなら分かりやすいんだ、へーｗ
正直、Gitが分かりにくいということが理解できない。
ユースケースをかいてこの場合はこの手順ってのを一まとめにしてあげたほうがいいんじゃないかな？
Gitを解説したブログとかチートシートがよく話題になってるけど、
入門Gitを読んだあとはどんな文献を読むと良いでしょうか
>795
その、どんなVCSを使おうが炎上しそうな条件設定で、何が語りたいの？
>>800 http://progit.org/book/ja/ch5-1.html 独裁者と若頭型のワークフロー
これは、複数リポジトリ型のワークフローのひとつです。
何百人もの開発者が参加するような巨大なプロジェクトで採用されています。
有名どころでは Linux カーネルがこの方式です。
統合マネージャーを何人も用意し、それぞれにリポジトリの特定の部分を担当させます。
彼らは若頭 (lieutenant) と呼ばれます。
そしてすべての若頭をまとめる統合マネージャーが「慈悲深い独裁者 (benevalent dictator)」です。
独裁者のリポジトリが基準リポジトリとなり、すべてのメンバーはこれをプルします。
commitするときのコメントを日本語にすると何か不都合あるかな？
大丈夫だ、問題ない
一番いい文字コードを頼む
807 ：
デフォルトの名無しさん ：2011/05/21(土) 11:26:34.61
>>798 チートシートっていわゆる日本語で言うとカンペだからね。
理解している人がチラ見するものだよねぇ。
>>808 良いこと言うね。たしかにその通りだ。
いいから早く使わせろ、って態度でやるから「Gitムズカシイ！！！」とか言い出すんだと思う。
自分のソースコードを任せるんだから、あやふやな理解で良いはずがない。
## トピックブランチを作成して作業
>>809 ローカルで細々とやってる分には
チートシート程度で理解できないツールは不便だがな
svn, cvs みたくサーバー準備が必要なわけでもなし
分散管理なら「はよ使わせろ」と普通に思うわ
>>811 集中型の思考回路のままで使うのじゃなければ、チートシートでもいけるんじゃないか。
例えばhgに慣れてる人なら。
>>810 mergeコマンドはカレントのブランチにマージするものだから、出来ないね。
てかマージはコンフリクトする可能性があるから、まずチェックアウトしないとその後が困る。
あと
＞git checkout -b master
の -b は要らないと思う。
低レベル操作によって、ワーキングディレクトリを一切無視して
>>812 それ「分かってるヤツがチートシートを読めば分かる」と言ってるだろw
>>812 >mergeコマンドはカレントのブランチにマージするものだから、出来ないね。
まあそうですね。
ありがとうございました。
>>814 例えばGit初めてでもhgに慣れ親しんでる人とCVS一本槍の人じゃ、チートシートの効果が全然違うでしょ
hg glog (graph log) に相当するのは、gitでは何でしたっけ？gitkとかはなしで。
>>756 >カレントブランチの変更はコマンドとして独立させて別名を与えるべきだった
>〇〇のチェックアウトが「〇〇ブランチへの移動」だなんて冷静に考えてやっぱり変だろう
同意。git swtich ブランチ名 にしてほしかった。
>>817 hg glogがどういうものかわからんけどgit log --graph --decorateでどう？
820 ：
デフォルトの名無しさん ：2011/05/22(日) 14:19:05.40
俺は[alias]にsw = checkout というむちゃなエイリアスしてる。
>>819 あーこれだこれ。ありがとうございます。
別の質問ですが、現在のブランチがどのブランチから分岐したものか調べる方法はありますか。
$ git checkout master
$ git checkout -b dev1
$ git commit
$ git commit
$ git checkout -b fix1
$ git commit
$ git branch | grep '^*'
* fix1
$ ## fix1 の分岐元がdev1であることを調べるには？
>>821 それ無いんだよねたぶん。。。ある意味必要かもしれないと思う。
hgにはあったりするのかな？
いちおう、git show-branch でそれっぽい事が分かるよ。
それっぽいというか、まさにその為のコマンドだけどな。
hgと同じってこと？
>>808 上手いこというな
自分でひと通り試した後カンペ(チートシート)を書くと覚えやすいし
後で見ても自分の言葉なので思い出しやすい
自分のためのチートシート書くのは本当にオススメ
質問です。
>>827 hgのtransplant拡張なら可能
>>827 git-svnとcherry-pickでいけるんじゃないかな。
あとGit的には２つのsvnリポジトリが同じになったタイミングでマージして起点を作っといたら
良い感じになりそうなものだけど、svnに戻すことを考えると、そうもいかないんだよなぁ。
git-cherry は童貞クンを探すコマンドで
831 ：
デフォルトの名無しさん ：2011/05/23(月) 07:30:00.89
>>810 この前に、pullしなくていいの？
＞## マスターブランチに戻ってマージ
＞git checkout -b master
＞git merge --no-ff dev-xxx
>>795 あのオプション群が腐ってないと思ってる方が理解できない
git-svnしたレポに対し、 rXXXXXX みたいなタグを10マンコ生成してみたけどいろいろ糞遅いよ? 死ぬの?
836 ：
デフォルトの名無しさん ：2011/06/01(水) 22:55:50.86
あるコミットからあるコミットまでの間に 変更のあったファイル
まずは git diff --stat a^..b から試せ。
Diffでもstat使えるんですね
github落ちてね？
.macとはえらい違いだな
まんこまんこ
846 ：
デフォルトの名無しさん ：2011/06/02(木) 20:39:01.34
滑ってる
まんこまんこおっさんはどこ?
Cygwin の Gitを使用しているのですが、EclipseやNetBeansで作成したファイルをcomittすると
"git core.filemode"でググれ
>>850 その設定はfalseにしているのですが、初回コミット時に755になってしまうのです…
まんこまんこだけど、そこそこ安定している msysgit-1.7.5 のありかきぼん。
そういやmsysgitの公式バイナリはまだ1.7.4なんだな
homebrew する必要があるかw
TDDのときにGitを使う上での便利な使い方とかありますか？
フックスクリプトとかそういう話を期待してんじゃね？
おまえら、ちょっと教えてくださりませんか。
> なぜか、このプロジェクトのきまりで設定ファイルをignoreに入れることができない。
>>858 プログラマ別に固有のリポジトリ/リモートブランチ持たせて
>>858 がmasterにマージすれば？
ignoreできないのもアホすぎるけど、各プログラマが自分で判断してマージする能力を持ち合わせてないように見える。
別人だけどついでに質問させてもらっても良いかな？
>>861 雛形のファイル(例えば config.yml.sample)を管理対象にして、
ローカルでは雛形をコピーかつ編集したもの(例えば config.yml)を使う、
という感じ？
Git使ってて必要のない変更までコミットしてしまうってのが
yes
ディレクトリごとコミットしてしまう人は、他のシステムでは稀に見る
gitだろうが何だろうが、余計な変更があったら邪魔なのには変わりないと思うが。
>859
自分で覚えようとしない人に覚えさせるってのはだいたいうまくいかない
自分で覚えようとしない人はこの業界自体あれだよな…
>>862 ああ、確かにそうするのが適切かもしれませんね。
sampleファイルの名称変更はビルドとかデプロイとかの中で行うわけですね。
というかgit ignore禁止に理由が知りたい
>>871 そんな設定して誤爆したら困るじゃないか
責任取れるのか？
>866
>868
git commit -a したところで untracked なファイルはコミットに含まれないはずだけど。
・そうしないと管理工数が増えて実開発時間が減ります
どっかコンフリクト起こした時点で開発ストップするがな。
手をかけようとするのをやめな
活発なオープンソースプロジェクトを独自変更で追いかけて行く（もちろんこっちの変更は取り込まれない）
Windows上で、Eclipseで作ったjavaファイルをCygwin Git で管理し始めました。
>>881 /etc/fstabにnoacl,notexecでどうだろう
どんな副作用が出るかは知らない
一般公開部分と非公開部分があるプロダクトを扱うことになったんだけど、
>>883 Aにhttpもしくはgitでのreadonlyサービスを置く。
とにかくAに対してBの非公開部分を晒さないように *運用に気をつける*
Bはsshとかで好き放題やってくれ。
おまけ。Aにpushできる人を、ヘマをしでかさない人たち(いわゆるリリースマネージャ)に限定。
でいいんではないか? さしあたっては A をGithubなどで運用するケースを考えてみるとよい。
tarballでのリリースでなくてリポジトリの公開か。
>>883 プロダクト毎にリポジトリを分けようとすると混乱する。
リポジトリは公開/非公開で分けて、パッケージングは別にすればいい。
>>884-886 回答どうもです
大元は同じコードなので、公開用と非公開用でブランチを割って
それぞれリポジトリA、Bみたいな感じでいけそうかな、と思います
>>882 ありがとうございます！
その単語でググったら色々情報ヒットしましたので参考にします。
まんこまんこだけど、まんこ(aka 100k refs)の話題をMLに投げてみたら、意外な方向に話が脱線してる。
会社でcvs使ってるんですけど、
~/Downloads/TESTA/TESTB:git revert 3036a5530069ed954fdd5e4b17cc95c87bd93680
error: could not revert 3036a55... 3
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
今日初めてGitに入門した新参です。
上のようにrevertしたいのにerrorになりました。
しかも、ファイルが下のように書き替えられちゃってるんですが、これ何が原因だと思いますか？？？？
~/Downloads/TESTA/TESTB:cat a.h
<<<<<<< HEAD
4
=======
2
>>>>>>> parent of 3036a55... 3
893 ：
891 ：2011/06/17(金) 07:18:00.57
もっと具体的にお願いします！
gitもこういうユーザが増えてきたってことか？
>>893 バージョン管理システム自体を使うのが初めて？
ヒント: hint
エラー：3036a55戻すことができませんでした... 3
ヒント：競合を解決した後、訂正後のパスをマーク
ヒント："RM<paths>をgitの'追加<paths>をgitの'かで
ヒント：ととの結果をコミットするには、"コミットgitの"
898 ：
デフォルトの名無しさん ：2011/06/17(金) 23:58:23.63
>>898 All your /usr are belong to us.
/usr 配下に重要なファイルをインスコするOSは傍流
>>900 /usr/homeがあるFreeBSDのことか
>>901 何を言うか、FreeBSDはpackageから/usr/localにインスコするではないか
…あれ、なんかすごいボケてたので↑はなしでｗ
入門Gitを斜め読みしています。(←難しくてぜんぶは理解できない...)
>>906 私も勉強中なので間違ってるかもしれませんが...
p.106ページの記述は
トピックごとにブランチ切ろう、ということを言っているだけであって、
トピック作業完了後rebaseすることの是非について言及しているわけではないと思います。
p.118の「リベースでまとめる」というのが
>>906 で記載されている方法に該当し、
特に非推奨の方法でもないと思います。
自分は
> (これはどこそこブランチからマージされました とかいうログだけのコミット)
> ができてしまって気持ち悪い
の場合にはmerge --no-commit でマージした後、手動でコミットしています。
>>906 何ページだったか忘れたけど、マージコミットを嫌うやり方もある一方で
どんどんマージするやり方もある、て書いてあるよ。
つまりrebaseしないのはバカって訳ではない。
例えばバグ修正してるのに余計なコミットを混ぜ混んでったらダメだ、ってことだよね。
tortoisegitのtgitcache.exeのバグは治った？
>>909 XP上のTortoiseGitで、ログウィンドウとかを閉じようとしてもなかなか閉じず、
やっと閉じたと思ったらTortoiseProc.exeが残ったままになるんだけど
同じバグかな？
906です。
>>913 まあ、ないよな
Macなんて誰も使ってないし
Tower(これもGitクライアントアプリ)に興味を持つ人なら
>>911 も試すんじゃないかな？
俺は試した。そっと終了したが。
そんなにダメなのか
Towerといい…なんでMacのGitアプリはCPU使用率がこんなに高いんだろう
まんこ詩んだ？
>>918 Macが重いのはPowerPC時代からの伝統だよ
2chの人たちはMac派は少ないのか？。。。
俺一応使ってるよ。
925 ：
デフォルトの名無しさん ：2011/06/24(金) 00:11:30.62
以前HFS+(Macのファイルシステム)でケースを区別するようにフォーマットし直したら、
>>923 Macは使ったことあるけど、自分の用途ではLinuxのほうが速いし楽だし便利だし
という結論になった
勉強会に出てるような人らって
そういえばおととしぐらいにOSSカンファレンス行ったら
twitter使いは猿が多いからどうしてもMac使いが多くなる
Webやってる連中はOSXが便利だな。つかWindowsがダメすぎ。
ＵｂｎｔやＣｅｎｔじゃだめなんかい？
プライベートならSUSEが安定してていいな
>>932 SUSEとやらは聞いたことがなかったな
他のlinuxディストリと比べて何が違うの？git方面で
>>933 統合環境としてのSUSEが便利なのであって、
gitというツールに着目したら他Linuxと大して変わらんぞ
githubとか(自分で作ったものでもそうだと思いますが)、リモートのリポジトリに対して
しばし待て。もしかして活動履歴から当該ブランチのハッシュが消え失せるまでプルーンされなかったりしてな!
TortoiseGitって細かいバグが多くて嫌だわ
>937
亀gitはバグ対応速度も亀並みなんやな・・・
日本語混じりのコミット(と、ログ)以外、コマンドラインで十分な体に飼いならされちゃったわい。
942 ：
937 ：2011/06/27(月) 12:37:17.98
Nightly build(1.7.0.0)を試してみたけど、バグは直るどころかひどくなった？
以前のバグが直らず放置されているのも多い
覚えているだけでも以下のバグが
・cherry-pickのとき、間違ったupstreamで表示される
・ログを検索したあと、検索を解除しようとしても戻らない
・cherry-pick(rebase)、ログで固まる
・ログ表示などで落ちる
・複数コミットのcherry-pickで、途中のが失敗していても続行
・cherry-pick(rebase)の後間違ったコミットにresetする
・
>>941 TortoiseProc.exeもよく残っていて有害
・TGitCache.exeはよくファイルをロックしたまま離さないので、Status Cacheはオフにしたまま
・変更されたファイルを表示しようとすると、少ないファイル数でも何時まで経っても終わらないことが
・TortoiseMergeが競合している行を表示しない
・ベアリポジトリでは使えない？（エクスプローラーでコンテキストメニューが表示されない）
一体どんな設計しているんだ！！
tortoiseproc.exe は勝手に死んでくれるからまだマシw
わざわざ不安定版を探して文句付けてるサディストがいると聞いて
ナイトリーにいちゃもんつけるとは
942じゃないが、いちゃもんつけちゃダメっていうなら何のためにナイトリービルド公開してるの？
ここでバグ報告してどうする
948 ：
942 ：2011/06/28(火) 03:12:10.44
>>944-945 ここで指摘してやらないと
>>942 に書いたレベルでリリースされかねないだろうが？
これまでのバージョン見る限りマジやりかねんわ
ここでバグ報告してどうする
英語書けないんだよ糞が
英晤じゃ無きゃダメなんて書いてないだろ
中国語で書かれたBugzilla PRがフルボッコ(ただし同胞のフォローがすこし)ってのを見たことがある。
>>942 が日本語でも英語でもいいからBugzlllaにチケット挙げないかな
いずれでもフルボッコにされそうで観戦してみたい
性格ねじ曲がった団塊みたいな意見ですね
そうだね、セールスの電話で遊ぶクソジジイっぽいよね
あれだけはマジで基地外じみている...
eclipse のオマケの EGit はどのように使うのでしょうか。
俺の肛門も管理されています
なんでわざわざEclipseのEGit使って小説管理するんだ
肛門集会と思ってうrl開いたのに…俺の肛門は閉鎖されちゃったよ。
version 1.7.6 はいかがでしょうか
>>960 ハアァアァアァアァアァァァアァァァァァァァァァァァァァァァァア？？？？？？
気持ち悪い？
あ
天使さん戻っておいでよ
make test でエラーが出てしまったわい
.
git status
git log
git diff
git commit
git rev-parse --git-dir | xargs rm -rf
おいやめろｗ
こまめに別のメディアへのバックアップをしましょうね
git clone --mirror
git revert
git rerere
git odekakedesuka
978 ：
デフォルトの名無しさん ：2011/07/07(木) 14:07:54.86
rerereはこのまえちょっと便利に感じた。
一度に複数の機能を追加してしまった場合に、
git add -p
そういう事態はgit add -i 使ってる
>>881 modeを無視するgit configの設定があったはず
filemodeだったか
git stash も悪くないよ。
git add -iの存在を忘れていたなあ。
>>982 その設定も行っているのですが、初回add時の属性は
ファイルシステムが認識しているものになるようです。
Git のマスコットって森林破壊してるけど、あれって何か意味あるのかな？
git init
git gc
git fsck
git sucks
git rebase
git wants 次スレ
結局みんなGitに流れたよね
git ume
ume chau zo
ume
まんこタグはあきらめてまんこnotesに趣旨替え。
うめ
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。
