トップページ⇒tech
1001コメント314KB

Git 2

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2010/09/14(火) 21:38:18
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

◆前スレ
git スレッド
http://hibari.2ch.net/test/read.cgi/linux/1197798039/

◆関連サイト
Git入門
http://www8.atwiki.jp/git_jp/
0002デフォルトの名無しさん2010/09/14(火) 21:44:46
◆関連スレ
バージョン管理システムについて語るスレ7 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1283780922/

CVS 1.3 [UNIX板]
http://hibari.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
【分散型バージョン管理】 Mercurial 【hg】 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
0003デフォルトの名無しさん2010/09/14(火) 22:02:22
◆関連書籍
入門Git [濱野 純 著／秀和システム]
http://www.shuwasystem.co.jp/products/7980html/2380.html
入門git [Travis Swicegood 著、でびあんぐる 監訳／オーム社]
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9
実用Git [Jon Loeliger 著、吉藤 英明 監訳、本間 雅洋、渡邉 健太郎、浜本 階生 訳／オライリー・ジャパン]
http://www.oreilly.co.jp/books/9784873114408/
0004デフォルトの名無しさん2010/09/14(火) 23:42:20
msysGit の UTF-8ファイル名対応版を作ってみた
一応、TortoiseGit からきちんとUTF-8ファイル名を扱えることを確認済み。
http://tmurakam.org/git/

Pro Git - Table of Contents
http://progit.org/book/ja/
0005デフォルトの名無しさん2010/09/14(火) 23:53:53
あら、レスをそのままコピペしちゃった
0006デフォルトの名無しさん2010/09/15(水) 00:02:15
Git - Fast Version Control System
http://git-scm.com/
0007デフォルトの名無しさん2010/09/15(水) 02:27:25
『ぎっと』ですか『じっと』ですか
0008デフォルトの名無しさん2010/09/15(水) 02:53:47
>>7
「ぎっと」
http://www.youtube.com/watch?v=4XpnKHJAok8
0009デフォルトの名無しさん2010/09/15(水) 05:54:28
gは大文字なんだっけ？ロゴは小文字だけど。
0010デフォルトの名無しさん2010/09/15(水) 08:37:16
名前としてはGit
コマンドとしてはgit
0011デフォルトの名無しさん2010/09/15(水) 09:52:11
Git は何の略ですか？
0012デフォルトの名無しさん2010/09/15(水) 11:27:41
Gitの略です
0013デフォルトの名無しさん2010/09/15(水) 16:15:48
丁寧にありがとうございました
0014デフォルトの名無しさん2010/09/16(木) 01:14:23
略じゃないw
gitどもめw
0015デフォルトの名無しさん2010/09/16(木) 01:24:26
cogitoは何と読むべきでしょうか
0016デフォルトの名無しさん2010/09/16(木) 07:57:47
>>15
cogito, ergo sum
0017デフォルトの名無しさん2010/09/19(日) 21:25:25
IrrlichtのSVNリポジトリをgit svn cloneでgitから使いたいのですが、
branchesフォルダの中がちょっと変な構成になっています。
branches/ogl-esとbranches/SkinnedMeshもブランチとして扱うにはどうすればいいですか

git svn clone https://irrlicht.svn.sourceforge.net/svnroot/irrlicht -T trunk -b branches/releases/ -t tags
0018172010/09/19(日) 22:13:10
branches/releases/はその下にバージョンを名前にしたフォルダが入っているのに、
branches/ogl-es/とbranches/SkinnedMeshはそのままファイルが入っています。
こんなブランチでも正しく扱う方法はあるんでしょうか
0019デフォルトの名無しさん2010/09/20(月) 00:28:52
結局Windows用GitはmsysGitを入れればOKと色々なブログとかに書いてあるが、
実際にインストールするのはmsysGitではなく、ただのGitと書かれたインストーラを指しているけど、
ある人は「頭にmsysがついているGitを入れろ」といわれました。

何を入れればいいのかよくわかりません。
0020デフォルトの名無しさん2010/09/20(月) 00:36:37
>>19
その人に聞けば良い
0021デフォルトの名無しさん2010/09/20(月) 01:00:38
>>20
その人も違いがわからんといってました。
両方入れてみたところ頭にmsysが付かないほうはGUIがあるみたいでした。
ではmsysが付くほうのメリットは？
また両方入れて問題はないでしょうか？

とりあえず、Git（またはmsysGit）＋TortoiseGitの組み合わせにしようと思います。
0022デフォルトの名無しさん2010/09/20(月) 01:08:19
前スレ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.
>
0023デフォルトの名無しさん2010/09/23(木) 01:50:24
公式のDownloadにWindowsとMacの項目が増えたね
0024デフォルトの名無しさん2010/09/23(木) 20:19:55
1.7.3キタんだけど、RelNotesのディレクトリ構造が変わってて、リンク切れしてるｗ
ttp://www.kernel.org/pub/software/scm/git/docs/RelNotes/1.7.3.txt
0025デフォルトの名無しさん2010/09/25(土) 13:55:31
Gitについて前から疑問があるのですが、誰かご存知でしょうか？
gitはハッシュ値で管理するということですが、百万が一バッティングした場合、
何か対処法があるのでしょうか？

まあ、まず有り得ないとは思いますが、どの資料にもこの話が載っていないので……
0026デフォルトの名無しさん2010/09/25(土) 14:06:54
蝙蝠本P42-44にsha1の衝突の可能性について書いてあるが
対処法は書いてない
0027デフォルトの名無しさん2010/09/25(土) 14:08:15
まあ原理的には基本アウトだよね
完璧に手作業でサルベージするしかない
公開してたら全員に連絡とる
めどい
0028デフォルトの名無しさん2010/09/25(土) 14:13:28
百万が一というより10^48が一だが
0029252010/09/25(土) 14:19:35
ありがとうございます。
やはり対策は打ってないか……Linusらしいといえばらしいですが。
0030デフォルトの名無しさん2010/09/25(土) 15:05:01
ハッシュの万能さ加減がGitの要になってるから、
衝突したらお手上げだよね。

世界中の総力を結集すれば見つけることは可能だろうけど、
同一プロジェクト内でぶつかりさえしなければ問題には
ならないから、まあどうにでもなるんじゃないかな。
0031デフォルトの名無しさん2010/09/25(土) 15:32:07
msysgit1.7.2.3とTortoiseGit1.5.3.0で使っていますが
Rebaseやcherry-pickを使うと、ダイアログを開いただけでTortoiseGitが落ちてしまいます。
Git Bashからなら使えるのですが、GUIが使えないのはやはり不便です。
ammendするときは前のコミットのメッセージが出るはずなんですが、何故か出なくなってます。
0032デフォルトの名無しさん2010/09/25(土) 16:51:20
>>31
これってRebase.cherry-pickしようとしたら落ちる？それともした結果のもの？
0033デフォルトの名無しさん2010/09/25(土) 16:54:08
>>28
えっと･･･もう少し具体的に
何分の一？
0034332010/09/25(土) 16:58:12
Googleに"10^48 in 日本語"と聞いても教えてくれない・・・
0035332010/09/25(土) 17:00:30
わかりました。
10^48=1000000000000000000000000000000000000000000000000=1極ですね。
納得

数の単位・日本の大きな数字の単位データ＞雑学データバンク
http://dorama.tank.jp/d/suujitanio.htm
0036デフォルトの名無しさん2010/09/25(土) 17:01:53
SHA1は2の80乗個のハッシュを作ったらどれか1個だけが50％で被る
0037デフォルトの名無しさん2010/09/25(土) 19:46:26
つまり、とりあえず生きてるうちにそういう状況にぶつかれる可能性はほとんどないってことだろwww
0038デフォルトの名無しさん2010/09/25(土) 19:59:46
確率論とは悲惨なもので、どんなに天文学的な確率を弾き出してても実際に起こるときはやっぱ起こる
カーネルのソースコードで起きないかなーとちょっと期待中
0039デフォルトの名無しさん2010/09/25(土) 20:02:52
どう見ても、ハードディスクやマシンの故障とかを気にするべきw
0040デフォルトの名無しさん2010/09/25(土) 20:08:29
DAGだから親がいないみなしごになるだけじゃ？
0041デフォルトの名無しさん2010/09/25(土) 20:52:59
どうなんだろ、オブジェクトIDがダブった時点で
・既にあるのおかしい！と異常終了
・気付かずにそのまま使ってぶっ壊れる（blobなのにcommitが出てきたり
　すると異常に気付くような気もする）
・リモート同士でダブった場合、push先のbareリポジトリでぶっ壊れる？
ぶつかったのが両方共同じオブジェクトタイプだったりすると、
けっこう面倒なことになりそうかも。

関係ないプロジェクト間ではいつか出そうな気もするけど、
Linuxカーネルのリポジトリで何年後かに出るようなことは…
強運の持ち主がけっこう居そうだから、意外に出ちゃうかもｗ
0042デフォルトの名無しさん2010/09/25(土) 21:05:19
一番リビジョンが多いのはやっぱりLinuxカーネルなのかな？
ハッシュ衝突したらニュースになるのかな？
0043デフォルトの名無しさん2010/09/25(土) 21:09:36
>>42
それはニュースになるでしょう。
カーネルがどうこうではなく、sha1ハッシュの脆弱性が考えられるから。
0044デフォルトの名無しさん2010/09/25(土) 21:19:00
すでにあるのと重複チェックは重くてできないか。
gitは全部のリビジョンを持ってこなくても良いから意味ないか。
0045デフォルトの名無しさん2010/09/25(土) 21:27:35
>>43
いや脆弱性も何もカブるのは単純な確率の問題
カブらないことは原理的にありえない
脆弱性とか関係ない

もし意図的にハッシュ値を同じにしたというのなら、昔ならニュースになった
今はSHA-1は既に現実的な時間で破られてるからニュースにもならない
0046デフォルトの名無しさん2010/09/25(土) 21:30:27
>>45
俺もあなたと同じこと思ったけど（書き込みまでしそうになったｗ）
>>43の人もそれは分かってるから、「脆弱性が考えられる」なんて
まわりくどい書き込み方したんでないの？
「現実的にはほぼ衝突しない、だが衝突した、これは果たして
本当に"運が悪かった"だけなのか？」という意味でニュースになるだろうと。
0047デフォルトの名無しさん2010/09/25(土) 22:01:05
ハッシュのコリジョンよりgitのバグの方を気にしろ、って事だろう
隕石が脳天直撃する事より交通事故を心配しろみたいな感じで
0048デフォルトの名無しさん2010/09/25(土) 22:09:38
hgも同じ感じのハッシュだけど、bzrはコミットユーザと時間とハッシュの連結みたい
0049デフォルトの名無しさん2010/09/25(土) 22:41:46
>>47
正に杞憂
0050デフォルトの名無しさん2010/09/25(土) 23:20:45
もし衝突したら、話題にはされるだろうけど、
commit log にしろ、ソースそのものにしろ、
改行 or スペース一個足せば、
解決するんでないの?
0051デフォルトの名無しさん2010/09/26(日) 00:17:35
可能性がゼロじゃないってだけで不安になるのは職業病だから仕方ないと思うけど
現実的には気にするほどのことでもないんじゃね
数百匹のサルがでたらめにタイプしてシェークスピアの作品をどうこうみたいなもので
0052デフォルトの名無しさん2010/09/26(日) 01:37:21
>>47
はははｗ
0053デフォルトの名無しさん2010/09/26(日) 01:38:37
>>50
落ちるかもわからない隕石は放っておいて、
もし落ちたら落ちたでその後処置すればいいわけですね、わかります
0054デフォルトの名無しさん2010/09/26(日) 02:39:26
人間いつか死ぬんだし
0055デフォルトの名無しさん2010/09/26(日) 08:24:45
>>53
よくわかってんじゃねーか
0056デフォルトの名無しさん2010/09/26(日) 08:47:22
ム板に来ると変なのが出てくるけど、文字コードの話はまだ？
0057デフォルトの名無しさん2010/09/26(日) 08:51:22
衝突するかもしれないようなものを衝突しないとして設計しているのはバグのある
設計であることは間違いないわけで、確率的にほとんどないからそれでいいんだ、
というのはコードを書く人間の態度しては良いとは言えない。
実際bzrのような回避策もあるわけだし。
0058デフォルトの名無しさん2010/09/26(日) 08:55:55
>>57
bzrってハッシュにユーザ名と時間くっつけてるんでしょ？
衝突の可能性としては同じだと思うんだけど。
0059デフォルトの名無しさん2010/09/26(日) 09:13:40
ハッシュ値が一度でも被ったなら、そのシステムの「被り回避」は信用ならない
絶対に被らないか、天文学的な確率でいつか絶対に被るか、どっちか

被ったらどうせそこで止まるんだし手作業でなんとかしようぜ、というのがgit
ほんのちょっと(SHA1の計算されたランダム性に比べたら本気でほんのちょっと)ハッシュ値を長くしただけで
「これで大丈夫対策ばっちり」とか無邪気に信じてるのがbzr
0060デフォルトの名無しさん2010/09/26(日) 09:18:49
てゆーかだな、
ファイルパス＋所有者名＋タイムスタンプではどうにも区別できないからこそハッシュ値を使用してるんであって、
わざわざハッシュ値にファイルパス＋所有者名＋タイムスタンプをいまさらくっつけても
ハッシュ値強度はほとんど何も変わらない
ハッシュ値としてユーザーフレンドリーであるという以上の意味はない
0061デフォルトの名無しさん2010/09/26(日) 09:19:24
ム板らしくなってきました。
bzrはbzr log --show-idsでないと出てこないみたい
0062デフォルトの名無しさん2010/09/26(日) 12:19:42
ハッシュ値の件だけど、将来のバージョンでSHA-256とかが使われる余地はあるんだろうか
全ユーザがそのバージョンに乗り換えないと使い物にならないだろうから絶望的な気がするが
0063デフォルトの名無しさん2010/09/26(日) 12:24:02
それはGitの次のアーキテクチャだと思う
実際上、Gitで衝突はまず起こらない
というか起きた人は挙手して欲しい所存
たぶんインタビューとか受けられるぞw
0064デフォルトの名無しさん2010/09/26(日) 13:38:59
gitに限らず、普通にハッシュが衝突したってだけでそれなりの話題になるのは必至だろうな
0065312010/09/26(日) 18:12:35
>>32
しようとしただけで落ちます。
ログ一覧からRebase(cherry-pick)を選択しただけで落ちます。
Git1.7.1なら大丈夫みたいなのでしばらくこれで行こうかと思います
0066デフォルトの名無しさん2010/09/26(日) 18:51:14
>>65
した結果が見えているんなら、TortoiseGitのバグだろうね。
0067デフォルトの名無しさん2010/09/27(月) 10:12:59
git svnをproxy環境下でも使う方法わかった
gitの設定ではなく、$HOME/.subversion/serversを変更しないといけなかったらしい

http://www.mail-archive.com/[email protected]/msg00745.html
0068デフォルトの名無しさん2010/09/27(月) 19:30:55
>>60
同じ所有者が同じタイムスタンプでcommitする操作なんてまずしないから
十分有効な回避策のはずですが。
git信者ですか？
0069デフォルトの名無しさん2010/09/27(月) 19:35:08
>>68
commitの--dateというオプションと
GIT_AUTHOR_DATE, GIT_COMMITTER_DATE 環境変数で時間なら操作できます
0070デフォルトの名無しさん2010/09/27(月) 19:40:17
rebaseだと時間順に並ばないから意味無いんだけどね
0071デフォルトの名無しさん2010/09/27(月) 21:39:47
>>68
「まずしない」ということが何を意味するのか、ハッシュ値の衝突が
「まずしない」と比較してどうなのか、考えてみよう。
0072デフォルトの名無しさん2010/09/27(月) 21:48:32
フロッピーの時間操作なんかまずしないもんね
0073デフォルトの名無しさん2010/09/27(月) 21:58:58
ユーザ名+時分秒+ランダム数字4ケタ くらいでまず重複しない

という発想の人はまれによくいる
0074デフォルトの名無しさん2010/09/27(月) 22:00:55
ぐへへ・・・タイムスタンプを衝突させてやるぜ
0075デフォルトの名無しさん2010/09/27(月) 22:03:13
ユーザー名とタイムスタンプで十分なのならハッシュ値なんて面倒なものそもそも使わないと何度でも何度でも言う
0076デフォルトの名無しさん2010/09/27(月) 22:11:47
というか、
　充分にランダムなハッシュ値Aを3桁くらい伸ばしとく
と
　ハッシュ値Aが衝突を起こした場合（に備えて）、ハッシュ値にユーザー名とタイムスタンプを付加してID値とする
はおおむね乱数ハッシュ値の強度的に同じだということに気づけない人がいるというのが
やっぱ日本の数学教育駄目だなあとかちょっと思う

ハッシュ値のこのbって書いてある部分を1個cにしたハッシュ作って、と言われても出来ないだろ
でも「このユーザー名全部大文字にして」は文字列操作ですぐ出来るだろ
そんなのハッシュじゃねえんだよ
ハッシュの唯一性を1ミリも強化できないんだよ
0077デフォルトの名無しさん2010/09/27(月) 22:20:22
gitは日本で作られたの？
主要コミッタは日本人だそうだけど
0078デフォルトの名無しさん2010/09/27(月) 22:26:28
そもそも外国製
日本人の人がその中で頑張った
0079デフォルトの名無しさん2010/09/27(月) 22:46:19
>>76
意図的にできるということと、偶然そうなってしまうということの違いを理解できない
人がいるということに問題を感じる。
0080デフォルトの名無しさん2010/09/27(月) 23:52:37
最近gitを使い始めたのですが、よくわからないので質問させてください。

　　　root_repo.git
というリモートリポジトリがあったとして、その内部に
　　　root_repo.git/dir1
　　　root_repo.git/dir2
　　　root_repo.git/dir3
という3つのディレクトリがあるとします。

これらのディレクトリに対して、
ユーザ1がローカルリポジトリを repo1 にコミット
　　　commit local_repo1 -> root_repo.git/repo1
ユーザ2がローカルリポジトリを repo2 にコミット
　　　commit local_repo2 -> root_repo.git/repo2

というような処理をはできないのでしょうか？
よろしくお願いします。
0081デフォルトの名無しさん2010/09/28(火) 00:35:48
>>80
Git的には意味不明だから、日本語で詳しく書くか、チュートリアルぐらい読んだ
ほうが良いと思う。
0082デフォルトの名無しさん2010/09/28(火) 00:41:06
>>80はbzrの共有リポジトリを言っているんじゃないかと思う
0083デフォルトの名無しさん2010/09/28(火) 01:27:04
>>81,82
返答ありがとうございます。

>>81
基本的に、各ユーザは自分の作りたいものに対するプログラムを書く予定です。
なので、本来は別々のリポジトリに分けた方がよいのかと思うのですが、

　　・ユーザが増えるたびにいちいちリポジトリを作るのが面倒
　　・利用者が自分でリポジトリ作るというのも避けたい（権限的な問題）

と考えてます。
なので、一つ全体的なリモートリポジトリを作っておき、その下にあるユーザ毎の
ディレクトリに対してローカルリポジトリをコミットできれば良いかと思いました。

そもそもめんどくさがるなという話なんですかね、これは。


>>82
Bazaarはディレクトリごとに管理してるんですね。
こっちならこのようにできそうな気が・・・。
少し調べてみます。
0084デフォルトの名無しさん2010/09/28(火) 01:29:36
>>77 >>78
日本人と言っても在米１５年以上の在米邦人だ。
現在はGoogle社員。
0085デフォルトの名無しさん2010/09/28(火) 02:27:47
>>83
Gitosisみたいなのでホスティングすればそういうのできるよ。

>>84
どっかのプロフィールではTwin Sun所属ってことになってたと思うんだけど、
ヘッドハントされたのかな。
0086デフォルトの名無しさん2010/09/28(火) 04:50:46
git svn でcloneしてくるときに、通常は --stdlayout, -sで持ってくると思いますが、
これはsvnのブランチがtrunk,tags,branchesを想定したものだと思います。

ところが、Subversionの自由にブランチをディレクトリに割り当てられるためか、
branches/hoge や branches/foobar のようなブラン構成ではなく、
branches/fuck/hoge や branches/fuck/foobar、branches/sine/piyo や branches/sine/piyopiyo
という2段構成のブランチになってしました。

これを --stdlayoutで引っ張ってくると、もってきたgitリポジトリの履歴がかなりメチャクチャになってしまうのですが、
上手く持ってくるような方法はないでしょうか？



0087デフォルトの名無しさん2010/09/28(火) 04:55:24
>>83
>>85 じゃないけど、github使う(privateや容量増は有料だけど)のもいいね
githubはユーザーごとに簡単にリモートリポジトリもてて
管理用のユーザーかリポジトリ作っておけば、そっちにも成果をマージできるでしょ

あとは、どこかのサーバーに中央リポジトリ用意して、
各個人ごとにリモートブランチきって突っ込むとかｗ
0088デフォルトの名無しさん2010/09/29(水) 01:53:46
タグ一覧するコマンドって無いのかな？
0089デフォルトの名無しさん2010/09/29(水) 02:38:58
>>88
git tag
0090デフォルトの名無しさん2010/09/29(水) 12:16:25
gitはSSHと組合せて使っている人が多いと思いますが
SSHの秘密鍵生成には確率的素数判定法を使っているはず:-)
0091デフォルトの名無しさん2010/09/30(木) 13:27:41
v1.7.3.1きた。stash が壊れてたらしい。
0092デフォルトの名無しさん2010/10/02(土) 18:29:39
告白というか、一緒に下校してほしい、みたいな感じ。
お互い徒歩通学で家まで１時間ぐらいかかるんだわ。
昨日からその子のことを下心でしか見てない自分が悲しい
0093デフォルトの名無しさん2010/10/02(土) 18:30:38
これはひどい誤爆…
すいません
0094デフォルトの名無しさん2010/10/02(土) 18:45:04
甘酸っぱいのうｗ甘酸っぱいのうｗｗ
0095デフォルトの名無しさん2010/10/02(土) 18:52:07
gitのスレタイで来たのなら、高度な誤爆
0096デフォルトの名無しさん2010/10/02(土) 19:07:47
>>93
絶対に許さない
0097デフォルトの名無しさん2010/10/02(土) 20:14:11
gitってあほ、ぼけ、間抜けって言う意味なんだねｗ
0098デフォルトの名無しさん2010/10/02(土) 21:16:07
なんだ俺のことか
0099デフォルトの名無しさん2010/10/02(土) 22:06:47
お前は間抜けなんかじゃないよ。自信を持とう。
0100デフォルトの名無しさん2010/10/02(土) 22:13:07
そうだ、お前は間抜けでも歯抜けでも毛抜けでもない！
0101デフォルトの名無しさん2010/10/03(日) 13:49:29
欝だ死のう
0102デフォルトの名無しさん2010/10/07(木) 14:21:35
話の流れをブッタギル様ですまん。

git 運用において、パッチはあくまでも機能単位であるべきなのだろうか?
たとえば "100ファイルに相互依存しない同様の変更を施したモノ"は
パッチ100本にすべきなのか、パッチ1本にすべきなのか迷う。

つかまとめあげたパッチを強制的にファイル単位にバラす方法知らん?
0103デフォルトの名無しさん2010/10/07(木) 20:08:27
git commit -m '#!/usr/bin/hogeを#!/usr/local/bin/hogeに変更' とか？
同様の変更ってことはある単一の意図でやったことだろうから
100個に分割するんじゃなく1個にまとめるべきなんでは
0104デフォルトの名無しさん2010/10/07(木) 21:46:08
運用次第だと思うが、git推奨はどんなのだろう

俺の場合、コミットログがバラバラになる場合はコミットはまとめないけど、
それでもまとめない場合はブランチ名つけておけばいいんちゃうのかな
0105デフォルトの名無しさん2010/10/07(木) 21:58:37
>>102
例えばそれが「インデントまとめて変更」とかだったら100ファイル一発でも
良いと思うが、100個のバグ修正だったら絶対に分けるべきだと思う。

俺の考えでは、誰かが分離したくなるかもしれない単位、で
世に出すのが良いのではないかと思う。
01061022010/10/08(金) 09:03:57
そゆ意味じゃ、テストスクリプト群への同様の修正なので、
100個のバグ修正ともいえるな。
0107デフォルトの名無しさん2010/10/08(金) 11:54:56
そもそもなんで同じ内容のものを100箇所に鏤めて置くんだ？
普通共通のファイルを一個作ってincludeなりなんなりするだろ
0108デフォルトの名無しさん2010/10/08(金) 13:05:29
テストプログラムに対するレビューは果たして必要か
0109デフォルトの名無しさん2010/10/08(金) 13:31:46
>>108
スレ違い
0110デフォルトの名無しさん2010/10/08(金) 14:01:22
わかった、じゃあスレ違いじゃない書き方にする。

>>109
他人のテストスクリプトに対してそういうケチを付ける気にはならないな、自分は。
0111デフォルトの名無しさん2010/10/08(金) 14:02:25
っぷっ
0112デフォルトの名無しさん2010/10/10(日) 17:17:16
rebaseしたら今いるブランチの最後のコミットだけ無くなった
どういう事なの・・・
0113デフォルトの名無しさん2010/10/10(日) 17:22:58
はぁ・・・復元する方法ないのかな・・・
0114デフォルトの名無しさん2010/10/10(日) 17:44:51
reflogすれば見つからないか？
0115デフォルトの名無しさん2010/10/10(日) 18:57:14
>>114
！！あった！！
ありがとう！
0116デフォルトの名無しさん2010/10/10(日) 22:39:25
>>112
ふつーは reflog でちまちま探すなんだけど、rebase する前にあらかじめ
git checkout -b b4rebase rebased みたいにくさびブランチを打っておくとよいぞ。

つか rebase がもっと柔軟にならんかね。って欲張りな悩みよね。
0117デフォルトの名無しさん2010/10/10(日) 22:41:39
カキコついでに質問だが、カスケードしたブランチを一発で rebase するいい方法、ない?

master->foo-bar->baz->qux みたいなブランチを、一気に直線 rebase するような感じの。
0118デフォルトの名無しさん2010/10/10(日) 22:50:43
>>116
rebase -i はけっこう柔軟だと思う。

>>117
普通に git rebase master qux じゃダメなん？
0119デフォルトの名無しさん2010/10/11(月) 12:15:53
>>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
と同じ結果にならないよね?
各ブランチがレビュー待ちのパッチを含んでいると想像してくれ。
0120デフォルトの名無しさん2010/10/11(月) 16:12:03
言い忘れ。かつ、各ブランチがそれぞれのマイルストーンを達成している。
0121デフォルトの名無しさん2010/10/11(月) 16:32:54
>>119
それをコマンド一発でやりたいってこと？
branch.name.mergeを元にして動くスクリプトを書いても良いと思うけど、
mergeと違って、元がrebaseしてる場合はコンフリクトする可能性大だから、
複数ブランチを一気にrebaseかけるのは怖いな。
手動でやったほうが良いんじゃないかね。

foo、bar、baz、quxはそれぞれテスト等も済んでるだろうから、
無理にrebaseするよりも、masterからfooにmergeしたほうが良いと思うな。
各ブランチがmasterの新機能を前提として必要になったのなら仕方がないけども。
濱野さんの入門Gitには、そのように書いてあった。

なかなか上流に取り込んでもらえないと、rebaseでキレイに並べて
おきたい気持ちは分かるんだけど…
0122デフォルトの名無しさん2010/10/12(火) 19:48:42
master ブランチにいるとき git merge origin で origin/master->master のマージが行われないのなんでだよ!
0123デフォルトの名無しさん2010/10/12(火) 19:56:42
>>122
git pullなら省略できる（適切に設定されてれば）
0124デフォルトの名無しさん2010/10/12(火) 20:46:28
すげー書き違え! まさにその git pull origin でカレントじゃない master の更新が行われず、
git push するたびに master について叱られるのだ。
master じゃほとんど作業しないし。

すまんこ
0125デフォルトの名無しさん2010/10/12(火) 23:54:22
自演乙
0126デフォルトの名無しさん2010/10/15(金) 10:32:34
TortoiseGitをプロキシ経由で使うのってどうやれば？
試しにSettingsでプロキシを有効にするよう設定してみましたが無理でした

Putty Fatal Error
Network error: Connection timed out
0127デフォルトの名無しさん2010/10/15(金) 16:18:44
うちでは正常に動作するよ
0128デフォルトの名無しさん2010/10/16(土) 01:11:54
PuttyってことはそれってPutty側で設定がいるんじゃ
外してるかも
0129デフォルトの名無しさん2010/10/20(水) 09:00:47
git svn で取得したリポジトリにて git describe がタグ振らずに機能するといいなあ。
0130デフォルトの名無しさん2010/10/23(土) 13:47:49
git commit -aを実行するとVimが起動します＞＜
0131デフォルトの名無しさん2010/10/23(土) 13:49:33
git commit -aを実行するとjedが起動
します＞＜
0132デフォルトの名無しさん2010/10/23(土) 13:54:48
git commit -aを実行するとパソコンが固まります＞＜
0133デフォルトの名無しさん2010/10/25(月) 14:27:04
もしかして、日本語でログメッセージ書くとStashに失敗する？
TortoiseGit1.5.8.0とGit1.7.3.1で使っているけど、ときどき失敗する。
しかもGit Command Progressのダイアログでは、ログメッセージに日本語が入っていると文字化けして表示される。
0134デフォルトの名無しさん2010/10/25(月) 14:32:37
なんかgit svnで取得したリモートブランチに対して、直接mergeをかけたら
svn側でしか変更してないはずなのにコンフリクトするんだけど、
もしかしてリモートブランチはマージ履歴持ってなかったりする？

git svn fetch #リモートブランチを更新
git merge --squash --no-commit git-svn #リモートの更新をmasterにマージ
# ここでコンフリクト
0135デフォルトの名無しさん2010/10/25(月) 15:21:51
>>134
今のところSVNでgitのマージコミットを表現することはできないから、
dcommitする予定のブランチではmergeしちゃダメだよ。
まず今のブランチをgit svn rebaseでSVNに追随させないといけない、んだけど
うまくrebaseできなそう。。。
git checkout -b mergetest git-svn してcherry-pickで整形し直したほうが
良いかもしれない。
0136デフォルトの名無しさん2010/10/25(月) 23:53:01
>>135
いや、svn側の変更をgitで追いかけているだけなんで、dcommitする予定はないんだ。
手元にはsvn fetchしているだけのリモートブランチ(デフォルト名のままgit-svn)と、
ローカルの変更込みのmasterがあるだけ。

cherry-pickしたほうがいいのかなあ。ありがとう。
0137デフォルトの名無しさん2010/10/26(火) 03:20:57
no-ffつけるとかそういう話じゃなくてか
0138デフォルトの名無しさん2010/10/26(火) 04:48:40
no-ffはsvnブランチ間のマージの話だったように思うけど……今度試してみる
0139デフォルトの名無しさん2010/10/26(火) 07:04:26
>>136
>>134をよく見たら --squash してるけど、前回もそうしてた？
それならコンフリクトするのも分かるよ。
squashで別のコミットとして作り直してるから、次にマージする時には
また同じコミットが対象になってしまう。コンテンツの内容が近いなら
うまい具合にマージ出来るかもしれないが、失敗する可能性も高い。
これはgit-svnに限らないgitの話。
git log master..git-svn で見ると既にマージ済みのが出てくるんじゃないかな。
0140デフォルトの名無しさん2010/10/26(火) 07:38:43
>>139
確かにgit log master..git-svnしたらsvn側の履歴が全部出てきた……。
svn側の複数の変更を、masterではひとつにまとめたかったんだけどなあ。
やってることはリモートブランチがsvnなだけでhttp://progit.org/book/ja/ch6-7.htmlと変わらないと思ってたんだけどなあ。
0141デフォルトの名無しさん2010/10/26(火) 08:02:41
前回merge --squashしたところからの三点マージができればいいんだけど、
そもそもgitで三点マージを行うのがrebaseか……。

どうせsvn側でしか変更はないんだから-Xtheirsでも付けるかな……。
0142デフォルトの名無しさん2010/10/26(火) 20:44:21
>>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他の配管コマンドでどうにかしたりする必要あり。
0143デフォルトの名無しさん2010/10/27(水) 02:47:53
read-treeに-mなんてあったのか。次からそれでやろう。ありがとう。
0144デフォルトの名無しさん2010/11/02(火) 15:12:03
ブランチaで8個ほど一つ一つ丁寧にコミットして
git svn rebase
git checkout master
git merge --no-ff a
git svn dcommit
したら「Merge branch 'a'」というたった1つのコミットになっていた件。
なんなんだこれは…
0145デフォルトの名無しさん2010/11/02(火) 17:36:48
>>144
>>135
0146デフォルトの名無しさん2010/11/04(木) 05:36:07
リモートリポジトリに真っさらなブランチをpush --forceしてしまいました
手元には元のソースは残っていません
復旧は不可能ですか？
0147デフォルトの名無しさん2010/11/04(木) 06:20:02
>>146
まず手元のリポジトリで git reflog してみる。それで見つかるかも知れない。
手元に無くても、分散してるどこかにあるかも知れない。

最悪のケースとして、pushした先のリポジトリにしか無かったという場合、
まずその.git（bareリポジトリならそのディレクトリそのもの）をバックアップ。
git fsck --lost-found を実行すると .git/lost-found/commit が出来るので、
そこから探す。

あまりあり得ないと思うけど、空pushした後に git gc が実行されていると
ポインタだけじゃなくてオブジェクトも消えているので、もうダメぽ。
0148デフォルトの名無しさん2010/11/06(土) 01:24:46
GitExtensions使ってる人いますか？
あれ、いつの間にか日本語対応しました？
0149デフォルトの名無しさん2010/11/06(土) 13:56:34
そんなのあるのか、使ってみよ
0150デフォルトの名無しさん2010/11/06(土) 23:49:36
過去の履歴を綺麗さっぱり消したいのですが可能でしょうか？
現在のHEADを１番目のコミットにしてしまいたいのです。
単純に.gitディレクトリを削除してinitし直せばいいのかな？
0151デフォルトの名無しさん2010/11/07(日) 00:36:17
>>150
ほんとに綺麗さっぱりなら.gitを消してinitしなおすのが簡単だね。
微妙に残すのなら、git checkout --orphanというのがあるので
これを利用すればrootコミットから作れる。
0152デフォルトの名無しさん2010/11/07(日) 03:02:04
なんか、こういうことをやりたい、ってのが先にある時にやり方が分からないことが多いのは
gitの思想によるものなのか、それとも単に分散バージョン管理に慣れていないからなのか、たまに分からなくなる。
特に、分散なんだからそれぐらいできてもよさそうじゃん、ってのができないとき…。
0153デフォルトの名無しさん2010/11/07(日) 03:31:14
例えばどういうこと？

逆引き的なドキュメントが少ないという話であれば
ProGit一通りよむとかなり解決するが
http://progit.org/book/ja/
0154デフォルトの名無しさん2010/11/07(日) 03:38:18
むしろgit使ってみて今までやりにくかったことが簡単にできてびっくりしたけど
Subversion使っていてこういう機能欲しかったんだ、というのがあったり
TortoiseSVNからコマンドラインに移行したのも理由だと思うが


ただ、>>152がいうのもわからなくはなくて、〇〇はrebaseでできる、といった場合に、
何故○○というコマンドじゃないのか？と思ったり、
もちろん基本的なコマンドは用意しとくから、各個人勝手にaliasしろや、
という一貫したなげやり感もUNIX的にはわからんでもないし、
出来る事多いからコマンドかなり増えるだろうし。

Bazaarは確か標準のaliasもあるしかなりコマンドあったはず。
どっちがいいかという話だな。GUIがメインならコマンド多くても気にならないんだけどね。


0155デフォルトの名無しさん2010/11/07(日) 03:59:41
gitは、もしPro Git（の日本語訳）がなければ、少しでも難しいことは
何もできなかっただろう、という気はする
0156デフォルトの名無しさん2010/11/07(日) 04:25:12
便利そうなんだよなあ。
それはわかってるんだけど、
どうも Mercurial から移行できない。
0157デフォルトの名無しさん2010/11/07(日) 04:25:50
Mercurialってどうなの？
0158デフォルトの名無しさん2010/11/07(日) 05:02:34
Mercurial は分散で高速なんだけど凝ったことしなきゃ svn なんかとそんなに変わらない感覚で使える。
git は便利な分だけ覚えなきゃなんないことがある。ちょっと感じが違うよね。

# Bazaar は Mercurial に近い上ロケールとかしっかり作ってあるけど遅そう。

Mercurial でいいや。とか思ってたんだけど、このスレ見てると、やっぱ git が気になってw
0159デフォルトの名無しさん2010/11/07(日) 05:08:52
ほー。今度使ってみようかな
0160デフォルトの名無しさん2010/11/07(日) 08:42:55
hgは基本機能は限定されているけど、hgに同梱されている拡張のMQを使えばほぼgitと同じことができる。
hgとgitは概念的にはかなり似ているけど、決定的に違うのがブランチの考え方。
hgの名前付きブランチがgitに無い。
0161デフォルトの名無しさん2010/11/07(日) 11:59:47
>>160
名前付きブランチってどういう感じのもの？
0162デフォルトの名無しさん2010/11/07(日) 12:30:21
> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのブランチにリビジョンの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
0163デフォルトの名無しさん2010/11/07(日) 12:35:01
すまん。肝心な所で間違った。

誤）
１つ１つのブランチにリビジョンの名前が埋め込まれている。
正）
１つ１つのリビジョンにブランチの名前が埋め込まれている。

> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのリビジョンにブランチの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
0164デフォルトの名無しさん2010/11/07(日) 12:51:30
>>163
なるほど、なんか分かった。確かにGitはブランチの名前自体には意味を持たないので、
最初使い始めの頃はそこに戸惑った気がする。この変更ってどこから（どのブランチから）
来たんだろ？って思った時によく分からないんだよね。
マージコミットのログメッセージにブランチ名が書かれるから、gitkとかで視覚的に見れば
なんとなく分かるけど、それでもFast-forwardだったりすると完全に統合されちゃうから、
masterでやった作業なんだかtopicでやった作業なんだか、一見分からない。
0165デフォルトの名無しさん2010/11/07(日) 12:55:13
俺も１人で開発する時はmercurialだな。
慣れてるからってのもあるが開発に全く無駄が入らない。
コミットを綺麗に整形したい時はgitを使う。
0166デフォルトの名無しさん2010/11/07(日) 17:25:47
GitExtensionでgit rebase -i 相当のことをするにはどうすればいい？
0167デフォルトの名無しさん2010/11/08(月) 03:02:41
Subversionのときはコミットミスっても気にならなかったが、
gitだと下手に直せるからつい気になるわ

>>164
履歴をフラットにしたくて気軽にrebaseすると、rebase前のブランチなくなって焦るわｗ
仕様上、当たり前なんだが

cherry-pickするか別のブランチ名つけろ、というのはそうなんだけど
0168デフォルトの名無しさん2010/11/08(月) 09:46:43
>>164
そこで git merge --no-ff
0169デフォルトの名無しさん2010/11/08(月) 10:46:33
fast-forward の意味がいまだにわからない‥‥
0170デフォルトの名無しさん2010/11/08(月) 17:11:03
>$ git checkout master
>$ git merge hotfix
>Updating f42c576..3a0874c
>Fast forward
>README | 1 -
>1 files changed, 0 insertions(+), 1 deletions(-)
>このマージ処理で 『Fast forward』 というフレーズが登場したのにお気づきでしょうか。マージ
>先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に
>進めたのです。言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットを
>マージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。マージ対象が分岐し
>ているわけではないからです。この処理のことを 『fast forward』 と言います。
0171デフォルトの名無しさん2010/11/09(火) 00:15:29
>>169
fast forward＝ブランチのポインタをずらすだけ

分岐してなければ、これでいけることが多い


分岐しててfast forwardしたければ、rebaseしてコミットを直線にして分岐なくせばfast forwardできるが、
以前のブランチなくなるから注意。
これ防ぐには別のブランチ名つけておけばよかったはず。


そういえばpush(git svn dcommit)したあとに間違えてgit commit --amendしてしまっていて、
fast forwardなmergeができずあとから気づいてあせったことある。
rebaseだと駄目で、cherry-pickでamendした分を飛ばして解決したが他にいい方法合ったのか
0172デフォルトの名無しさん2010/11/09(火) 02:47:58
分かった気がする
ブランチの方に進んだだけの状態と、
ブランチの方に進んで一方masterの方も進んでいる状態の
2パターンでmasterにマージしてみたら前者だけがfast-forwardって出たわ。
前者は別にマージする必要というか絶対コンフリクトしないから
ただポインタをブランチの先頭だったところにずらしました、ってことだな
0173デフォルトの名無しさん2010/11/10(水) 17:09:04
git checkout の対象がブランチか、ディレクトリか判断つかないとき
git checkout dir/ とやってみたらディレクトリに反応して俺すげー
とおもってマニュアル見たら git checkout -- dir とすりゃよかったのな
0174デフォルトの名無しさん2010/11/11(木) 09:40:29
>>172
fast-forward mergeとそうでないmergeは、gitk --allでマージ前とマージ後を見ながら視覚的に確認するとわかりやすいよ
0175デフォルトの名無しさん2010/11/11(木) 10:28:02
gitk --all やってみたらマージで混乱してた頃の
枝がはちゃめちゃに混線しててワロタ
0176デフォルトの名無しさん2010/11/12(金) 11:44:13
書いてたらgit関係ないことに気づいたけどそのまま投稿するね

githubで公開されてるライブラリがあるのです
で、そのライブラリのバグを直そうと思いました
でも、バグ近辺関連のテストが全然ない上に、この訂正の適用前後で微妙に動作が変わります

・訂正前のメソッド動作はこういう単体テストを満たすものでした（を自作で追加する）
・訂正前と訂正後でこのように動作が変わりますつまりこの訂正コードは正当です
・訂正後のメソッド全体の単体テストです

の3種類のテストが、少なくともpullリクエストでの説得に必要な気がするのです
うまいまとめ方ないでしょうか
訂正後のメソッドについてのテストだけだと、
「この動作は以前のコードではどうだったの？」という情報がなくて困りそうで
0177デフォルトの名無しさん2010/11/12(金) 11:58:45
githubのpullリクエストの現在の挙動は、
ブランチに対してリクエストを出して、その後、そのブランチにコミットを追加すると、pullリクエストも伸びていく。
だから、pullリクエストはブランチ単位で分けた方が良いのでは？
マージするかどうかは、そのリクエスト先が判断すれば良い気がする。
0178デフォルトの名無しさん2010/11/12(金) 12:07:11
ブランチ単位で説得して、ブランチの中のどのコミットを採用するかはまぁすたぁに任せる
だから普通に「○○を改善するブランチ」を作って、
訂正前コードに対するテストをコミットして(a)、
比較対照テストをコミットして(b)、
比較対照テストの部分を極力編集しないように訂正後のコードに対するテストをコミット(c)すればいいのでは
まぁすたぁはおそらく
「コミットすべてを見て納得して、(a)と(c)だけ受け入れ、適当にCHANGELOGを書く」
ということをするはず

…慣れてればな
…慣れてればね
慣れてないと「こんな大きいの無理です入りませんいやっやめてっ」とか返事が返ってくる
0179デフォルトの名無しさん2010/11/12(金) 20:18:51
このへんの作法みたいなのの説明ってあんまりないよね
他者と関わりあっていかなければならないソフトウェアなのにさ
0180デフォルトの名無しさん2010/11/14(日) 09:59:04
パッチはメールの本文にベタで置かないと読まないとかいうプロジェクト管理者もいるし、
いろいろなソフトをひとまとめにできるルールなんて作れない
0181デフォルトの名無しさん2010/11/15(月) 10:33:41
gistが壊れてないか？
"New Gist"でPublic Gistを作ると
無関係のランダムな既存のgistからforkしたみたいになる
Privateだと起こらなかった。昨日から使い始めたんだか元々こうなの？
0182デフォルトの名無しさん2010/11/15(月) 10:52:46
https://github.com/blog/744-today-s-outage
0183デフォルトの名無しさん2010/11/15(月) 13:10:36
700000番から直ったみたい>gist
0184デフォルトの名無しさん2010/11/15(月) 17:16:20
git cvsimportを始めてからもうすぐ20時間。
進行状況の表示もまったくないしいつになったら終わるんだこれは・・・
0185デフォルトの名無しさん2010/11/15(月) 19:26:19
俺も以前cvsimportしたことあるけど、めっちゃ時間かかった上に
異常終了してたような気がするな。。。
ローカルにあるならまだしも、リモートではもうやりたくないと思った。
0186デフォルトの名無しさん2010/11/16(火) 02:54:10
git svnも小さいプロジェクトなのに最初のcloneに小一日かかったわｗ
0187デフォルトの名無しさん2010/11/16(火) 03:21:07
>>186
githubとかにもありそうな著名なプロジェクトなら、こういう手もある
git-svnを途中から始める - unpushの日記
http://d.hatena.ne.jp/unpush/20090826/1251281749
0188デフォルトの名無しさん2010/11/17(水) 10:51:13
cherrypickのたびに1文字1文字コミット名を入力するのが大変なのですが，
簡単に入力できる仕組みはあるのでしょうか？
解説等を読んでも引数にSHAの頭数桁を指定しているだけで・・
0189デフォルトの名無しさん2010/11/17(水) 11:44:01
>>188
ハッシュの意味をよーく考えよう
0190デフォルトの名無しさん2010/11/17(水) 15:50:39
>>188
ターミナルからコピペするの楽だから大変と思ったことないな。
master~5みたいな記法使ったらどうだろ？
0191デフォルトの名無しさん2010/11/17(水) 15:55:33
ああそうか、現在表示してるコミットのハッシュ値をマウス等でコピーできない環境なのか
それは使用環境が糞だというしかないな
0192デフォルトの名無しさん2010/11/17(水) 16:37:39
マウスなくてもscreenでコピペしてる。
zshやbashならハッシュ一覧表示する補完関数書けばいけるかも。
0193デフォルトの名無しさん2010/11/17(水) 17:09:01
最初の2文字ぐらい打てばほぼ一発補完できるeshellというかEmacs最強
0194デフォルトの名無しさん2010/11/17(水) 18:37:54
環境はMacです．
Terminalなのでコピペできるんですが，
どうしてもUNIXの保管になれてると少しだけ入力してTabで保管してくれないのかなー
等と欲がでてしまって・・（マウスも使っていないのでタッチパッドだとやりづらいorz）

Git自体にそういった保管機能はないということですね・・
git log --oneline で地道に拾います・・
0195デフォルトの名無しさん2010/11/17(水) 20:17:47
>>194
マウス使わないなら尚更screenがいいよ
0196デフォルトの名無しさん2010/11/18(木) 03:08:53
てかSHA1を直打ちしなくていいように refs/heads があるんだと思うんだが、、、
0197デフォルトの名無しさん2010/11/18(木) 06:20:40
>>196
こんなのあったんだ。

これってローカルのブランチ名と違うの？
ローカルのブランチ名に近い範囲だったら >>190の記法でいけるんじゃないの
0198デフォルトの名無しさん2010/11/18(木) 08:00:45
>>197
ローカルブランチと同じだよ。
refs/heads/〜とかrefs/remotes/〜とかはそこまでを省略して指定することができる。
ちなみに.git/HOGEHOGEとかを勝手に作ってもgit log HOGEHOGEとか出来ちゃう。
0199デフォルトの名無しさん2010/11/18(木) 11:08:08
へぇー、ORIG_HEADって定数が使えるのも .git/ORIG_HEAD の中を見てたってことなのか。
0200デフォルトの名無しさん2010/11/19(金) 11:17:35
ということは.gitをgitで管理すればブランチの変異もバージョン管理できるわけか
0201デフォルトの名無しさん2010/11/19(金) 11:23:35
>>179
githubについてはドキュメント足りないよね
pullリクエストを送るボタンの押し方なんて本気でどうでもいい

pullリクエストとして送る予定のコミットのいい書き方とか
pullリクエストの受け入れ方とか吟味の仕方とか説明がない
0202デフォルトの名無しさん2010/11/22(月) 02:59:59
>>194
一意に決まる場合はハッシュの頭数文字だけの入力で適切に処理される。
0203デフォルトの名無しさん2010/11/22(月) 03:19:55
今試してみたら、最低でも４文字は必要ぽい
0204デフォルトの名無しさん2010/11/27(土) 00:44:29
git add .
git commit -m "git boy"

としてindexに追加、コミットした後で余計なファイルをコミットしていたと気づいたので
ファイルはそのままにコミット前に戻したいと考えました。
（実際にはCygwinでファイルのモードを変更したつもりがないのに、
core.filemode = falseにし忘れていて意図せずファイルのモードが変更されまでがaddしてしまったのです）

　git reset --soft HEAD^

のように編集したファイルはそのままにしてコミットを取り消すことが出来ますが、

　git add .

が取り消すことができませんでした。

そこで、
　git add -r --cached .
としたのですが、git addしたもの以外も全て取り除いてしまうようです。

git addしたもののみ的確に取り消すにはどうしたらよいでしょうか？

0205デフォルトの名無しさん2010/11/27(土) 01:11:11
git reset head で、いいんじゃないかな
0206デフォルトの名無しさん2010/11/27(土) 01:25:12
>>205
あれ？それでいいんだ
いけました

ありがとうございました！
0207デフォルトの名無しさん2010/11/27(土) 13:17:58
複数のサブプロジェクトをひとつのリポジトリで管理するときの指針やコツみたいなのがあったら教えてください。
0208デフォルトの名無しさん2010/11/27(土) 13:35:42
>>207
gitosis
0209デフォルトの名無しさん2010/11/27(土) 15:06:43
>>208
そういう意味じゃないんじゃない？
submodule とか？　でもあんま使い勝手良くないんだよねぇ。
0210デフォルトの名無しさん2010/11/29(月) 02:29:52
Gitならこの人に聞け！
というぐらいのGit使いが身近にいればな・・・
名古屋近辺にいないかな？
0211デフォルトの名無しさん2010/11/29(月) 10:04:51
>>210
ttp://atnd.org/events/7556
のような集まりに参加すればいいんじゃないか。
ひとまず git 名古屋 でググれ。
0212デフォルトの名無しさん2010/11/29(月) 12:04:24
A：共用リポジトリ（自動的にDにプッシュ）
B:個人修正用リポジトリ（自動的にCにプッシュ）
C:修正＆テスター確認用ディレクトリ
D：本番適用待ちディレクトリ
　
D ---- RepoA (master)　　　RepoB (master) ---- C
　　　　　　　｜＿＿＿＿＿＿＿＿＿｜
　　　　　　　　　　　　　T
　　　　　　　　　　　　Local

現在上記のような形でローカルでブランチを切り替えて運用しているのですが
このような形だと当然だとは思いますが、歴史がおかしいとしょっちゅう怒られ、
サクサクと作業をすすめることができません・・
例えばRepoBには修正過程のゴミコミットがたまり続けるので
修正が完了してRepoA用のブランチにマージする際、
その修正をrebase -iでまとめてからRepoAブランチからcherry-pickしているのですが、
これをやってしまうと別の作業でRepoBにプッシュすると怒られてしまうという状態です

もっと上手な運用方法はないでしょうか・・
0213デフォルトの名無しさん2010/11/29(月) 12:47:15
リモートのリポジトリって1個じゃだめなの？
0214デフォルトの名無しさん2010/11/29(月) 13:11:34
＞RepoBにプッシュすると怒られてしまう

RepoAに切り替える
(RepoBのものを)整形したコミットをpush

RepoBに切り替える
ゴミコミットを取り消すためreset --hard
RepoAからcherry-pick
push

もしかしてresetした？それなら怒られて当然だ
普通に1つの共用リポジトリで
masterとstableブランチ作って運用するのじゃ駄目なの？
0215デフォルトの名無しさん2010/11/29(月) 14:20:47
RepoBをなぜ使用しているかというと
開発に参加している各人がRepoBを持っていたほうが
お互いの修正がバッティングしにくいと考えたためです

RepoAに各人のブランチを作る方法も考えたのですが
開発に参加する人数が増えるとそのたびにブランチを切らないといけないのかなーと・・
どのみち各人のRepoBを作成しているのでそのほうがめんどくさいかもしれない・・ですね・・・
0216デフォルトの名無しさん2010/11/29(月) 14:29:14
開発者各自はどうせ自前の作業用リポジトリを持つんだろうから、
・各自そこから中央にpush
・メンテナが各自からpull
のどっちかをやって、その都度当事者が責任を持ってコンフリクトを解消する。

お互いの修正がバッティングするのは分散して作業していれば必ず起こりうることで、
どこかでそれを解消したらそれ（マージされた状態）を保持しつづけるようにする
姿勢が必要。rebaseやcherry-pickしたら、された側のブランチは捨てるつもりで
やる必要がある。
0217デフォルトの名無しさん2010/11/29(月) 22:37:21
>>215
個人用のリポジトリRepoBを外にも持つ理由がわからない。
冗長性を保つためだけの存在なら、ローカルから直接本番のリポジトリRepoAにプッシュせず、RepoBでブランチ切ってmasterへのマージ時にRepoAへプッシュするようHookさせたらいいんじゃないか？
0218デフォルトの名無しさん2010/11/30(火) 03:28:14
>>210
とりあえず@bleisさんという人が詳しいみたいです。
どんな人か知りませんが。
0219デフォルトの名無しさん2010/11/30(火) 17:53:39
一月前のエントリだが。
http://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html
0220デフォルトの名無しさん2010/12/01(水) 08:41:10
マスタがsvnだとどうしてもrebase主義にならざるおえない。…追えない!?
0221デフォルトの名無しさん2010/12/01(水) 08:50:24
はいはいワロスワロス
0222デフォルトの名無しさん2010/12/01(水) 16:16:08
>>220
ﾅｶｰﾏ
git svn使うときはrebaseしまくりだわ

でも最近面倒なのでsvnにあるまじきリモートブランチ切りまくり
0223デフォルトの名無しさん2010/12/01(水) 17:02:16
svnの人が居ると最終的にsvnにrebaseしないといけないのって泣けてくるよね。
svn側でブランチとか作ってもけっきょくただのコピーだし、gitから見れば別モノなわけで。
svnのDBにGit互換の世界が作れればいいんだけどねぇ。propsとかでどうにかならないかな。
0224デフォルトの名無しさん2010/12/01(水) 22:46:16
無理にgit-svnで連携させようと思うのがいけないのだと悟った
.svnと.gitが共存するスペースを作れば種々の問題が解決した
0225デフォルトの名無しさん2010/12/01(水) 22:58:09
それって削除ファイルがあったときにめんどくね？
0226デフォルトの名無しさん2010/12/01(水) 23:01:32
コンフリクトした時も痛いことになりそうだ
0227デフォルトの名無しさん2010/12/01(水) 23:34:57
svnからupdateする時はその都度branchを切るな
大した手間じゃないし
0228デフォルトの名無しさん2010/12/02(木) 00:02:45
Macのデザイナーさんがよろこびそうなgitクライアントきてた
Tower - The most powerful Git client for Mac
http://www.git-tower.com/

0229デフォルトの名無しさん2010/12/02(木) 00:25:06
>>228
やたらオサレだな。gitもマカーにかかればこうなるのかｗ
0230デフォルトの名無しさん2010/12/02(木) 00:52:12
まだ使ってないから見た目でしか判断できないけどこりゃ…すごい…
毎回思うんだがgoogleの機能紹介アニメ作る人とか、レタッチツールやDAWのデベロッパには劣等感を感じてしまう。
飛車と角が合体したような連中ってのはいるもんなんだな。
0231デフォルトの名無しさん2010/12/02(木) 01:03:46
こりゃいいなｗ
0232デフォルトの名無しさん2010/12/02(木) 02:33:05
>>228
http://www.git-tower.com/img/screenshots/history_recent_big.jpg
うける
0233デフォルトの名無しさん2010/12/02(木) 11:02:16
git mergetoolでP4Merge使ってるんだけどマージした後にgit statusすると
modifiedとなる場合とならずにNot currently on branchとだけ表示されてcontinueできない
0234デフォルトの名無しさん2010/12/02(木) 23:30:20
>>230
Queen最強、と思ってたらKnightによくヤられる
0235デフォルトの名無しさん2010/12/02(木) 23:34:35
紹介しておいてなんだけどMacじゃないから試せない・・・
試した人感想くれ


gitじゃないけどBzrExplorerはいい線いっていると思うけどね。
次に何すればいいかってのが分かる。

バージョン管理ソフトばかりの話しではないけど慣れないときに困るのが、なにすればいいねん？ってことだからな
0236デフォルトの名無しさん2010/12/03(金) 00:53:57
GitX風だな。
0237デフォルトの名無しさん2010/12/03(金) 01:22:15
これいいとおもったらコミットメッセージ日本語うてないなｗ
0238デフォルトの名無しさん2010/12/03(金) 08:59:01
git-svnには完全には対応してないだと！？まーしょーがないか。
が、俺の感想。
0239デフォルトの名無しさん2010/12/07(火) 09:11:31
>>4
これが日本語ファイル名を扱う唯一の手段？
みんな日本語ファイル名をどうやって扱ってるのかな？
コードは日本語ファイル名はないと思うけど、ドキュメントとか普通日本語でしょ。
ドキュメントはバージョン管理しないの？
0240デフォルトの名無しさん2010/12/07(火) 09:27:13
追記
クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合
0241デフォルトの名無しさん2010/12/07(火) 09:38:48
http://code.google.com/p/msysgit/issues/detail?id=80
0242デフォルトの名無しさん2010/12/07(火) 09:42:31
ヨハネスやる気無さ杉だろ
0243デフォルトの名無しさん2010/12/07(火) 11:20:19
>>239
cygwin使えば使えるらしい
0244デフォルトの名無しさん2010/12/07(火) 12:11:54
SVNはちゃんと日本語ファイル名扱える(Linux/Windows間でも問題なし)のだけど
あれはどうやって解決してるんだろう
0245デフォルトの名無しさん2010/12/07(火) 12:18:38
パスとログはUTF-8と決まっていてクライアントが自動的に変換してる
0246デフォルトの名無しさん2010/12/07(火) 12:19:20
なんでGitだとそんな簡単なことが出来ないんだろう
0247デフォルトの名無しさん2010/12/07(火) 12:20:37
まあ少なくとも
「UTF-8決め打ちでプログラムがファイルパスを自動変換する」
という台詞を見て何も感じない人向けのソフトウェアではない
0248デフォルトの名無しさん2010/12/07(火) 12:34:12
>>245
違うよ。LANGで勝手に変換しちゃうんだよ。大きなお世話、勘違いだけど。
それが簡単だと思っているんなら、SubversionかBazaar使って満足していれば？
0249デフォルトの名無しさん2010/12/07(火) 12:49:46
エンコーディングを自動判定してるなんて一言も言ってないのに
特定プラットフォーム限定のLANGとか持ち出して勘違いとか言われても
0250デフォルトの名無しさん2010/12/07(火) 12:55:49
>>249
SubversionとBazaarがLANGで勝手に判定する勘違いアプリってこと
0251デフォルトの名無しさん2010/12/07(火) 13:09:26
日本人でさえ混乱してるのに
ヨハネスが上手く作りこめる訳がないな
0252デフォルトの名無しさん2010/12/07(火) 13:23:09
あらゆる意味で「日本人しかうまく作れない」と思う
おまえ日本人か、みたいな日本語べったりの外国人エンジニアなら可能かもしれんがまあ稀だな

俺らがやるヨーロッパ系言語のISO-8859-Xの扱いがへにょいのと同じ理屈
0253デフォルトの名無しさん2010/12/07(火) 16:40:43
>>240
クライアントが「SJIS」のWindowsマシンは世界中どこにも存在しない。
CP932ならあるけど。
0254デフォルトの名無しさん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 登録名。

0255デフォルトの名無しさん2010/12/07(火) 16:48:18
これも

SJIS
Shift_JIS の短縮形。Java では Shift_JIS と同義語。
0256デフォルトの名無しさん2010/12/07(火) 16:50:36
だから何？
0257デフォルトの名無しさん2010/12/07(火) 16:51:00
文盲乙
0258デフォルトの名無しさん2010/12/07(火) 16:53:31
SJISじゃなくてCP932って言いたいだけちゃうんかと
0259デフォルトの名無しさん2010/12/07(火) 16:54:43
しかし、文脈によってはベンダ拡張されたコードセットを指している場合もある。

しかし、文脈によってはベンダ拡張されたコードセットを指している場合もある。

しかし、文脈によってはベンダ拡張されたコードセットを指している場合もある。
0260デフォルトの名無しさん2010/12/07(火) 16:58:04
>>240
> 追記
> クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合

Linuxが主環境のgitスレに書き込むのなら、きちんとお勉強してから書き込みましょう、ということ。
0261デフォルトの名無しさん2010/12/07(火) 16:59:14
まず日本語の勉強したほうがいいんじゃないですか？
0262デフォルトの名無しさん2010/12/07(火) 17:01:51
261 ：あぼーん [あぼーん] ：あぼーん
0263デフォルトの名無しさん2010/12/07(火) 17:18:05
>>261
「クライアント」の意味が分からないので教えてください
0264デフォルトの名無しさん2010/12/07(火) 17:26:47
それは　えいごです
0265デフォルトの名無しさん2010/12/07(火) 19:22:55
> クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合
これがgit的に意味不明。
Linuxのリポジトリがbareなら日本語うんぬんは全く関係ない。
0266デフォルトの名無しさん2010/12/07(火) 21:35:58
エスパーすれば、それをLinux上でもcloneしたりするんだろ
何の為かは知らないけど
0267デフォルトの名無しさん2010/12/08(水) 01:21:31
CP932
SJIS
SHIFT_JIS
MBCS
Windows-31J
なんでこんなに色々あるの
0268デフォルトの名無しさん2010/12/08(水) 01:58:15
>>267
すっげえ単純に言うと、
コンピュータのメモリが有限で、
なおかつ帳簿を印刷するための文字が互いに足りなかったから

一昔前のPHSとケータイの絵文字競争に近い
「○○が表示できる」という理由でPHSやケータイを切り替えたのと同じ事が、
昔はコンピュータシステムレベルで起きた
0269デフォルトの名無しさん2010/12/08(水) 10:16:18
>>267
詳しいことはこのスレを参照ってことで、
http://hibari.2ch.net/test/read.cgi/tech/1274937437/
昔はSJISとCP932の違いは￥と〜の半角だけ気をつけていれば良かったのだが、
Unicodeが絡むとカオスが増す
0270デフォルトの名無しさん2010/12/08(水) 10:48:05
>>239
cygwinのgitでUTF-8で使えば大体いける。
少なくともUTF-8のLinuxとWindowsの間では自分の使っている範囲ではいけてる。

Mac OSXはシラネ。
よく比較対象に上がるけど、Mac OSXとLinux、Windows間はSubversionやBazaarでも大丈夫なのかよ
0271デフォルトの名無しさん2010/12/08(水) 10:54:16
盛り上がっているところ失礼します。

CRLFでコミットしたリポジトリがあるのですが、
手元にLFのファイルを上書きしたところCRLFとLFが異なると判定され、かなり多くのファイルが変更されたとみなされてしまいます。

リポジトリ内のCRLFのソースと、ただ編集されていないコミットしていない手元のLFのソースは
変更されていないように扱うことはできないものでしょうか？


こちらでcore.autocrlfの設定を試しましたが、うまくいきませんでした

core.autocrlfは未設定で使っておりデフォルトではOff(CRLFやLFの変換なしにそのままコミットされる)だったと思います。
core.autocrlfをtrueにしてもすでにコミットされたソースには関係が内容で解決せず、
また、core.autocrlfをinputにしても同様でした。
02722712010/12/08(水) 14:30:00
自分でも何がしたいのが整理したところ、
CRLFとLFが混在していても上手くmergeしたいというところまでわかりました。
(本来ならば、過去のコミットのCRLFをLFにrebaseか何かで簡単に変えられればよいのかもしれませんが…)

git-merge
http://stackoverflow.com/questions/861995/is-it-possible-for-git-merge-to-ignore-line-ending-differences
git-diff to ignore ^M - Stack Overflow
http://stackoverflow.com/questions/1889559/git-diff-to-ignore-m

検索してこちらのサイトを見ていたのですが、

git diff --ignore-space-at-eol

で差分は見られるようですが、さすがに git merge --ignore-space-at-eol のような簡単にできる機能はいかないようですね
0273デフォルトの名無しさん2010/12/08(水) 20:08:25
merge がconflictして mergeが面倒なだけなら、そのCRLFのリポジトリのファイルを
dos2unixなりで一括変換してコミットしてからmergeすればいいのでは。
blame の情報はなくなちゃうけど。

一つ目のリンク先も同じこと書いてた。autocrlfをセットして全部 touch してcommitしたらどうかって。
0274デフォルトの名無しさん2010/12/08(水) 21:22:30
>>270
> Mac OSXはシラネ。
> よく比較対象に上がるけど、Mac OSXとLinux、Windows間はSubversionやBazaarでも大丈夫なのかよ
大丈夫じゃないよ。SubversionやBazaarは、ファイル名にUnicodeを使っていれば大丈夫だと思っている情弱向け
0275デフォルトの名無しさん2010/12/08(水) 22:58:53
それでもgitよりsvn,bzrがマシなのに変わりは……
0276デフォルトの名無しさん2010/12/09(木) 16:39:28
git reset --hard
で消した操作って元に戻せますか？
0277デフォルトの名無しさん2010/12/09(木) 19:53:11
>>276
コミットしてなくてもgit add済みだったならgit lost-found で捜せば見つかるかも知れない
0278デフォルトの名無しさん2010/12/10(金) 09:16:16
git reflog -5
で確認して
git reset --hard HEAD@{1}
みたいなので戻れるんじゃね？
0279デフォルトの名無しさん2010/12/10(金) 11:14:04
~/src
をgitで管理

~/src/sub-project1
~/src/sub-project2
それぞれのサブディレクトリでも .gitを作って管理

なんてことできますか？
0280デフォルトの名無しさん2010/12/10(金) 11:19:29
>>279
Pro Git - Pro Git 6.6 Git のさまざまなツール サブモジュール
http://progit.org/book/ja/ch6-6.html
0281デフォルトの名無しさん2010/12/10(金) 11:23:14
あるディレクトリ以下の
*.c
*.cpp
*.h
*.cxx
*.pl
などの添え字のファイルだけgit add する方法ないのでしょうか？
findコマンドでみつけたものをパイプでgitに渡せばいいのでしょうか？
0282デフォルトの名無しさん2010/12/10(金) 12:30:54
cpp と cxx まぜてんのかい。
シェル(と設定)によっては git add **/*.{c,cpp,cxx,cc,C,h,pl} とかできるぞ。
find だと複数パターンの指定が面倒
find . -name '*.c' -o -name '*.h' -print0 | xargs -0r git add
0283デフォルトの名無しさん2010/12/11(土) 11:27:13
Gitで特定のファイルのみ管理したいときに、
.gitignoreで*.*で一度すべてを対象外にした上で、!.cや!.hとかで特定のファイルのみ管理対象にする。。。
みたいなことをしたら邪道といわれましたが、やはり管理したくないファイルを指定したほうがいいのでしょうか？

0284デフォルトの名無しさん2010/12/11(土) 11:29:48
れっつごーまいうぇい！
0285デフォルトの名無しさん2010/12/11(土) 11:58:22
addし忘れ多発しそう
0286デフォルトの名無しさん2010/12/12(日) 08:29:05
git submodule
で
~/src/sub-project1
~/src/sub-project1/sub-project11
~/src/sub-project2
みたいにsub-sub-projectを扱うとき

~/src/sub-project1/sub-project11
で何か変更あると

cd ~/src/sub-project1/sub-project11
git commit -a -m 'comment'
cd ..
git commit -a -m 'comment'
cd ..
git commit -a -m 'comment'

と３回もcommit しないと~/srcのgitに情報が反映されないので
cloneするとき不便

なんとかならないもの？
0287デフォルトの名無しさん2010/12/12(日) 12:10:47
>>286
cloneを三回
0288デフォルトの名無しさん2010/12/13(月) 06:01:42
ssh 経由で使うとsubmoduleがうまくpullできない
nfsでマウントし合わないとだめっぽい
0289デフォルトの名無しさん2010/12/13(月) 10:06:42
git svn dcommit
で競合がおきます
リモートの状態を手元の状態に強制的にあわせるコマンドはないのでしょうか
0290デフォルトの名無しさん2010/12/13(月) 18:56:01
>>289
git svn dcommitする前にgit svn rebaseするべき
0291デフォルトの名無しさん2010/12/14(火) 00:01:59
git svn rebaseって使っても大丈夫なのかな・・・と思うので

ローカルブランチを作って作業しておいて、
SVNのブランチに切り替えた後
ローカルブランチのコミットをcherry-pickする

という風にしてる
0292デフォルトの名無しさん2010/12/14(火) 00:24:54
くろうしてるなー(ぼうよみ
0293デフォルトの名無しさん2010/12/14(火) 07:12:04
git svn rebaseって要はsvn updateでしょ?
なにが心配なんだ…?
0294デフォルトの名無しさん2010/12/14(火) 10:17:48
もうperforceにするわ
0295デフォルトの名無しさん2010/12/14(火) 20:19:44
gitで共同開発する場合、
git --bare initして共有リポジトリを作るのが通常だと思います。
しかし共有レポジトリのコミットは弄れないし、共有リポジトリから他へpushすることも出来ません。

mercurialのように双方向にpush出来るような仕組みはgitには無いのでしょうか？
mercurialの場合、全てのリポジトリが同等で、どのリポジトリからどのリポジトリにpushするのも自由です。
こういう管理に慣れているとgitの共有リポジトリがとても融通の利かないものに感じてしまいます。
0296デフォルトの名無しさん2010/12/14(火) 21:05:28
bare やめて detached commit をチェックアウトしておけばドッペルゲンガー
じゃなかったグレムリンに遭わないよ。

お互いが ip reachable だったら双方向 push/pull はできるはずだけど?
0297デフォルトの名無しさん2010/12/14(火) 21:17:14
>>295
そもそもgitも特定の共有リポジトリを作ることの方が邪道。
02982952010/12/14(火) 22:07:53
>>296
>>297
ありがとうございます。

＞detached commit
これは初めて聞きました。

＞そもそもgitも特定の共有リポジトリを作ることの方が邪道。
これも初耳です。。

う〜む、単純に自分の勉強不足のようです。
もっと勉強してみます。
参考になりました。ありがとうございました。
0299デフォルトの名無しさん2010/12/14(火) 22:18:57
bareの話題ついでに聞きたいんだけど、
bareにする利点ってある？

プロジェクト管理のRedmineがbare要求するんで、.git指定したらそのまま通ったので面倒なのでそのまま使っちゃてるけど
0300デフォルトの名無しさん2010/12/14(火) 23:15:39
>>299
push先が変なのをチェックアウトしてたりdirtyなワーキングディレクトリになってると
pushが通らなくなることがあるけどbareだとその心配がない、とかかなあ。
公開用のリポジトリで、そこで作業することはないっていう保証とか約束みたいなもんだと思う。
0301デフォルトの名無しさん2010/12/18(土) 10:19:19
git-scm.comメンテナから緊急のお願い
Please read: An urgent appeal from git-scm.com maintainer Scott Chacon
http://git-scm.com/appeal

Oracleの話が出てたりしてちょっと危機感ありますね。
githubとか儲かってるらしいんだから支援してくれてもよさそうな気がするんだけどなぁ。
0302デフォルトの名無しさん2010/12/18(土) 14:07:38
>>301
https://github.com/schacon/gitscm/commit/813b98fcccbdb5e72cb6d552ae995ef294be8234
0303デフォルトの名無しさん2010/12/18(土) 14:09:28
git-scm.comってRailsだったんだ
0304デフォルトの名無しさん2010/12/18(土) 16:25:15
他のプロジェクトで開発されているソースを取り込んで
自分のプログラムを管理する、つまり
http://progit.org/book/ja/ch6-6.html
みたいなことを行いたいと考えています。

上のURL先のように直接rackのリポジトリをsubmodule化すると
rackに対して自分用の改変が行えない(文中にある「公開サーバにプッシュ」が行えない)
と思うのですが、実際にはどのようにすべきなのでしょうか？
03053012010/12/18(土) 18:58:54
>>302-303
げ、あんなのをRailsでやってるのか！？
おかしいな、ただのリンク集だよね、あのサイト。Wikiとかも別サイトだし。
そんなのをRailsみたいな重たいので実装しといて、費用がかかるからどうこうって、
どういうことなんだろ。
って思ってたら消したみたい。
https://github.com/schacon/gitscm/commit/eef57d0
ふざけてんなしかし。

元々Gitの公式サイトはgit.or.czで、いつしかgit-scm.comにリダイレクトされるように
なったんだけど、デザインが変わっただけなんだと思ってたよ。
http://git.or.cz/index.html

>>304
rackをフォークした公開リポジトリを用意してそこにpushとか？
0306デフォルトの名無しさん2010/12/18(土) 20:00:02
慣れてるなら SCM 的に使いやすいし、ページキャッシュをきちんと使うとかプ
リレンダするとかすれば充分軽いんだから、git + Rails でもいいじゃないで
すか。しかし、年間数百万ドルもかかるとは...
# Donations made will actually go to the Git project under the
# Software Freedom Conservancy.
0307デフォルトの名無しさん2010/12/19(日) 03:03:01
railsが重いっていつの時代だ？
0308デフォルトの名無しさん2010/12/19(日) 05:24:01
すげーメモリ食うよ
0309デフォルトの名無しさん2010/12/19(日) 05:54:25
もともと静的ページいくつかで済んでたのをわざわざRails。
まあ、いい。それでやってける自信があったんだろう。
しかし案の定、リソースが足りね〜つって「緊急の寄付のお願い、
さもなくば広告貼るか。Oracleは高く買うみたいｗ」って頭おかしいだろ。
これだからRails界隈の連中はクソだってんだよ。Githubも同様の奴原。
0310デフォルトの名無しさん2010/12/19(日) 05:55:29
Railsは「重い」よ

そりゃRailsを*ユーザーたちが*重く感じないようにリソース大量にぶち込めば重くはないだろうけど
そうしなければならないということはそもそもひとつの処理が重いんだよ
0311デフォルトの名無しさん2010/12/19(日) 14:54:02
>>309
# Donations made will actually go to the Git project under the
# Software Freedom Conservancy.
0312デフォルトの名無しさん2010/12/19(日) 16:09:40
まったくだ アセンブラで書いて速度と容量を最適化すべき
0313デフォルトの名無しさん2010/12/19(日) 16:14:06
>>311
だから？
0314デフォルトの名無しさん2010/12/19(日) 17:59:00
Rails(Ruby)が流行りだったんだよ、文句いうな
しっかし、まだPHPの方が速そうだよなぁ、PHP嫌いだけど
0315デフォルトの名無しさん2010/12/19(日) 21:04:33
そこでJRuby
0316デフォルトの名無しさん2010/12/19(日) 21:16:06
>>314
git-scm.com見てみろよ。PHPである必要すらないだろ。。。
チャリンコで済むようなところにわざわざレーシングカーみたいなの持ってきて
ガス代足りないからカンパしてくれって言ってるようなもん。
流行ってるからとかいう話じゃない。
0317デフォルトの名無しさん2010/12/19(日) 21:48:06
経験上だけどpassenger使わなければRailsはそんな重くない。
passengerはメモリ馬鹿食いするし、あれで嫌になってる人が多いのだろう。
0318デフォルトの名無しさん2010/12/19(日) 23:07:22
freetypeのgitリポジトリにつながらない　何で
03193042010/12/20(月) 01:03:40
>>305
ありがとうございます。
やっぱりリポジトリは2つ必要になるんですね…
0320デフォルトの名無しさん2010/12/20(月) 02:52:16
>>316
いやいやいやいや、
寄付してくれれてのはクリスマス限定のジョークのつもりだったんだってば。
寄付先は自分じゃないし、こっそり This page is a parody. とか書いてあるぞ。
0321デフォルトの名無しさん2010/12/20(月) 06:30:18
>>320
なるほど、最近のWikipediaの寄付アピールのパロディなのか。
だいたいまだクリスマスじゃないし、笑えないし、公開後すぐ隠したりでグダグダすぎる。
せめてエイプリルフールにしろっての。
0322デフォルトの名無しさん2010/12/20(月) 08:34:28
>>319
submoduleを使う場合はリポジトリを入れ子にして使うことになるので
両方公開するとしたら別々になるね。

サブツリーマージって方法もあるけど、、、こっちも分かりにくいけど、
submoduleよりはマシのような気がしないでもないかなぁ。
0323デフォルトの名無しさん2010/12/20(月) 13:08:21
騙された人は必死にならず「あー騙されたぜ、はっはっは」と言えるくらいの
ゆとりを持ちましょう
0324デフォルトの名無しさん2010/12/20(月) 13:33:44
せやな
0325デフォルトの名無しさん2010/12/20(月) 15:03:26
笑えないジョークだから半日で消したんだよ。
そうじゃなければクリスマスまでやるでしょ。
0326デフォルトの名無しさん2010/12/20(月) 15:34:41
もう一度同じこと書いてやろうか？
0327デフォルトの名無しさん2010/12/20(月) 15:39:27
せやなｗｗｗ
やっぱ味噌ラーメン以外考えられんわ、ってな訳で解散
0328デフォルトの名無しさん2010/12/20(月) 16:08:04
同じこと書くのはやめろ。ちゃんと自分の意見を書いてみろ。
0329デフォルトの名無しさん2010/12/20(月) 20:29:04
オレの意見:

ハートキャッチプリキュアが終わったら生きていけない
0330デフォルトの名無しさん2010/12/21(火) 07:18:08
>>301
あなた本気で言っているなら相当頭悪いですよw
0331デフォルトの名無しさん2010/12/21(火) 09:56:12
一番前まで戻るなよw
0332デフォルトの名無しさん2010/12/21(火) 13:23:41
オレの意見:

インデックスは俺の嫁
0333デフォルトの名無しさん2010/12/21(火) 17:03:00
自分のsrcディレクトリ　~/src　に、他人のコードが便利そうだから
pull してもってくると

~/src 以下の ~/src/some_projectにpullしたのを展開してほしいのに
~/src 以下に全部展開されてしまいます

~/src/some_projectにpullしたのを展開する方法ないのでしょうか
0334デフォルトの名無しさん2010/12/24(金) 13:54:53
>>333
cd ~/src; git pull http://example.com/333.git

or

git pull http://example.com/333.git ~/src/333
0335デフォルトの名無しさん2010/12/24(金) 13:55:54
ごめんpullじゃなくてcloneだった
0336デフォルトの名無しさん2010/12/27(月) 15:37:19
pullとfetchとcloneの違いはなんなんでしょうか
0337デフォルトの名無しさん2010/12/27(月) 15:41:11
>>336
http://progit.org/book/ja/
0338デフォルトの名無しさん2010/12/27(月) 22:17:46
漢は黙って git init -> git fetch
0339デフォルトの名無しさん2010/12/29(水) 22:44:16
git svn cloneで途中のリビジョンから複製したら
共通祖先がなくてマージできない
＼(^o^)／ｵﾜﾀ
0340デフォルトの名無しさん2010/12/29(水) 23:06:25
svnからcloneした履歴はマージしないほうがいいけどね
0341デフォルトの名無しさん2010/12/29(水) 23:11:44
>>340
え？・・・ああ、svnリポジトリの方は大丈だ夫
読み取りだけでdcommitはしない（出来ない）から。

問題はpushしたgitリポジトリの方だ・・・
またリモートのリポジトリ、作りなおさなきゃ
0342デフォルトの名無しさん2010/12/29(水) 23:19:48
>>341
よくわからないが、同じツリーのコミットを見つけてマージしちゃうってのはどう？
一度マージしちゃえば共通祖先が出来る。まあヘンテコな履歴になるけどね。
0343デフォルトの名無しさん2010/12/29(水) 23:35:02
svnの安定版ブランチからgitのブランチを作って、
それをpushしてソースコードを共有していたんだけど

svnのtrunkからの変更を取り込みたくなって、(gitのブランチで)マージを実行したら
全てのファイルがConflictして、共通祖先が無いことに気づいた
>>342
安定版ブランチだけ孤立している状態なんだけど、解決方法あるのかな・・・
0344デフォルトの名無しさん2010/12/30(木) 01:13:42
>>343
そういうことか。。。キツいね。
svnのほうはmerge-trackingでマージしてるんだろうね。

svnのほうで、安定版ブランチとtrunkの足並みが揃ってるところがあったら
Gitのほうでもそこからフォークしたことにしてやればけっこうコンフリクト減ると思うけど、
そうでなければ地道にcherry-pickして履歴作ってみたり、とかかなぁ。
git-svnがmerge-trackingをサポート、、、するわけないよなぁ。
0345デフォルトの名無しさん2010/12/30(木) 15:35:59
ちょっと質問いいでしょうか

とある既存の(特に公開リポジトリはなしの)ソフトやソースを編集して特にブランチなしで気軽にgit管理し始めました。(my_repo)

バージョンアップの度にリリースされたファイルの変化に追従していくうちに、変化を追うのが面倒になってしまいました。
この場合、リリースされたものだけを入れたブランチかリポジトリをつくって、
そちらを自分のmasterにマージしていけば楽なのではないのか？というところまで気付きました。

そこでどうするのがよいのか？ということなのです。

疑問点は、

・git initで新たなリポジトリをつくり、今からでもそこに手元にある旧バージョンから新バージョンをコミットしていって・・・？？
　全く異なる別のリポジトリをmy_repoにマージできるのか？
・既存のものから一旦(場合によってはgit cloneして)ブランチを切りたいが、
　my_repoで最初にコミットしたときにはすでにリリースされたものより違うため派生しにくい
・そもそも根本が異なるリポジトリは扱えるのか？


0346デフォルトの名無しさん2010/12/30(木) 15:37:35
途中で送信してしまった・・・・

このような疑問点は試したりドキュメントを読めば分かるのですが、
こういうときのベストプラクティスというものはないのでしょうか？

こういう事情の時はこうしたほうがよいのでは？ということをお聞きしたいのです。
0347デフォルトの名無しさん2010/12/31(金) 05:18:36
> バージョンアップの度にリリースされたファイルの変化に追従していくうちに、変化を追うのが面倒になってしまいました。

これがよくわからないけど、リリース時にgit tag v1.0.1とかタグ打っておけばgit diff v1.0.0..v1.0.1で差分は見れるけどそういうことじゃないくて？
0348デフォルトの名無しさん2010/12/31(金) 08:13:03
変化を追わないのならただのバックアップだよな…？
0349デフォルトの名無しさん2010/12/31(金) 08:34:05
>>345
> とある既存の(特に公開リポジトリはなしの)ソフトやソース

これを、素直にリポジトリとして作成する

んで、そこからcloneしてmy_repoブランチを切れば、みんながgithubでやってるような形になるんじゃないかと？
違いは、そのオリジナルのリポジトリを更新するのが、オリジナル開発者か自分かの違い、ってだけで。

でも、今あるmy_repoの履歴も捨てたくないから、この new_my_repo にmy_repoをマージできるか、ってことかな
どうなんだろ
0350デフォルトの名無しさん2010/12/31(金) 14:36:33
>>348
世代間バックアップくらいの気持ちで最初は使ってました。
gitは実開発でも使っているので、せっかくだし他の用途にも使ってみようかと。

>>349
前半までは理解しています。

> でも、今あるmy_repoの履歴も捨てたくないから、この new_my_repo にmy_repoをマージできるか、ってことかな

問題はここなんです。

実際の開発でもルート(というのかわからないですが。最初のコミット？)がことなる同じプロジェクトをどう扱うか？
ということをたまに迷います。

極論を言えば、手動cherrypickというか今のmy_repoの各コミットをパッチに吐いてnew_my_repoにとりこめばいいわけですし、
もしくは逆にmy_repoじゃない別途管理している既存のソフトの方で >>347さんのように差分とって
よければパッチはいて、my_repoに取り込めばいいわけですし

人によってはログや履歴を捨てることを躊躇しない人も今までいました。
しかし個人的な感覚としてそれらはちょっと気持ち悪かったのでシステムで解決できるもっといい方法がないかと思いまして
0351デフォルトの名無しさん2011/01/02(日) 17:06:11
git 自体のバージョンが違う、複数のマシンで
共同開発すると不都合ありますよね？

やはりコミットする人全員のバージョンは揃えておくものなのでしょうか？
0352デフォルトの名無しさん2011/01/02(日) 17:55:08
バージョン違うことによる不都合って「git log --onelineで見てみて」「エラー出ました！」
とかいう人間同士のコミュニケーション部分くらいしか思いつかない
0353デフォルトの名無しさん2011/01/02(日) 23:31:13
git rebase -i では操作対象コミットの中で最古のものより1つ古いコミットを
指定する必要があると認識しているのだけど、そうすると、最も古い(git init
直後の）コミットと最近のコミットをsquashでまとめることは不可能?
現在のコミット総数は10未満。

0354デフォルトの名無しさん2011/01/03(月) 00:52:30
root commitに触手を伸ばそうとしている勇者であることは理解できた。
0355デフォルトの名無しさん2011/01/03(月) 04:49:26
rm -rf .git/; git init; git add .; git commit -m "first commit";
0356デフォルトの名無しさん2011/01/03(月) 06:50:49
>>355
最後の手段w
0357デフォルトの名無しさん2011/01/03(月) 23:24:02
>>354
root commitっていうんだ調べてみます

>>355-356
やってみます！ありが
0358デフォルトの名無しさん2011/01/03(月) 23:38:09
gitってcloneするときにリモートリポジトリもやっぱり全部もってきてる？
git branch -aでリモートブランチにもその場でcheckoutできるようだけど

それにしては速くてびっくりした
0359デフォルトの名無しさん2011/01/04(火) 00:32:50
$ git rebase -i 最古のコミット
最古のコミットに混ぜたいコミットを一番上に移動して、push→editに変更
$ git reset --soft HEAD^
$ git commit --amend
$ git rebase --continue
でなんとなく望みの状態になったような気がします。
0360デフォルトの名無しさん2011/01/04(火) 01:18:15
TortoiseGit の日本語化ってできないの
0361デフォルトの名無しさん2011/01/10(月) 00:08:38
git svnで、ブランチとして扱うディレクトリって
「特定のフォルダの下のディレクトリ全て」ではなくて、
「特定の名前のディレクトリ」のように指定できる？
03623612011/01/11(火) 01:28:21
こんなふうにすれば、出来るみたい
"branches/*"の最後の*を消したら
One '*' is needed in glob: 'branches/hoge'
のように出たので、このメッセージでググッたら、偶然方法を発見した。

[svn-remote "svn"]
branches = branches/{hoge}:refs/remotes/*
0363デフォルトの名無しさん2011/01/15(土) 14:21:46
>>360
1.3.2.0向けのはあるけど、開発止まってる
だから自分で言語パックを作ろうとしたのだけれども・・・
入れてみてもコンテキストメニュー以外が全て英語のままだ、なんでだろう
0364デフォルトの名無しさん2011/01/17(月) 21:44:19
cvsのexportみたいなことって、
gitではどうやればいいですか？
0365デフォルトの名無しさん2011/01/17(月) 22:17:06
管理情報なしの状態が欲しいならcloneから.gitまるごと消すだけ。
アーカイブを作りたいならgit archive
0366デフォルトの名無しさん2011/01/18(火) 07:29:29
しかしコミット中に今はなきラージオブジェクトがある場合なんか、
cloneは大げさな気はする。というかよくそのcloneで固まる
0367デフォルトの名無しさん2011/01/18(火) 08:46:33
git archiveはデフォルトでtarアーカイブを標準出力に吐き出すので、
cloneするより パイプで (cd 目的地 && tar xf -) がいいかな。
0368デフォルトの名無しさん2011/01/18(火) 22:33:17
上流が git-svn rebase (ただしリードオンリー)してて
各個人が git-svn dcommit したい場合の
具体的なワークフローが知りたい

いや教えてください
0369デフォルトの名無しさん2011/01/18(火) 23:01:28
直接dcommitするなら、上流はsvnってことになるんじゃない？
0370デフォルトの名無しさん2011/01/20(木) 09:22:22
>>350
cd new_my_repo
git remote add my_repo ../my_repo
git pull my_repo master
0371デフォルトの名無しさん2011/01/23(日) 23:57:38
日本語で書いたログメッセージはちゃんとUTF-8で保存されてんの？
0372デフォルトの名無しさん2011/01/24(月) 01:07:10
UTF-8で書けばな
0373デフォルトの名無しさん2011/01/25(火) 01:00:08
あるブランチのコミットが別のブランチに全部取り込まれてるか簡単に確認する方法
教えてください
0374デフォルトの名無しさん2011/01/25(火) 01:36:19
>>373
実際にマージしてみる。
0375デフォルトの名無しさん2011/01/25(火) 13:18:17
>>373
git cherry A B
何も出てこなければBのコミットは全てAに入っている
0376デフォルトの名無しさん2011/01/25(火) 22:55:07
>>374
マージされちゃいます＞＜；

>>375
ありがとうございます
0377デフォルトの名無しさん2011/01/26(水) 01:48:53
マージしてもプッシュしなきゃよか。
リセット操作に抵抗あるならディレクトリごと別にコピーして試すがよか。
0378デフォルトの名無しさん2011/01/26(水) 12:19:38
ファイルシステムとしての Git
http://d.hatena.ne.jp/propella/20110105/p1
0379デフォルトの名無しさん2011/01/31(月) 18:06:23
1.7.4 released
ttp://article.gmane.org/gmane.comp.version-control.git/165718
0380デフォルトの名無しさん2011/02/01(火) 14:47:45
masterがメインで走ってて、安定版をFastForwardでstableブランチにmergeしていってるよくある
リポジトリで、コミットAとCとFとがstableだったってstableの履歴のようなもの知りたいのですが、
何か手はないでしょうか？
0381デフォルトの名無しさん2011/02/01(火) 17:06:21
git tag
03823802011/02/01(火) 17:27:50
それが tag のふられてない既存リポジトリなんですよ
つまりは手はなしってことですか
0383デフォルトの名無しさん2011/02/01(火) 21:20:01
>>380
リアルタイムで追いかけて merge とか cherry-pick があったときに tag とか branch でくさび入れるがよろし!
0384デフォルトの名無しさん2011/02/02(水) 00:02:23
tagって任意のhashにつけられるんじゃなかったっけ？
0385デフォルトの名無しさん2011/02/02(水) 00:45:24
いつの間にかTortoiseGitが1.6.3.0にバージョンアップしてた
03863802011/02/02(水) 09:36:52
具体的にいうとx264のgitリポジトリなんだけどね
masterがどんどん走ってて、ここまでならstable!ってポリシーで行ってるの
はいいけど、１個前２個前のstableをcoしたい。ってのができなくて。
committer が >>383 の言うように "stable:r1875" みたいなtag打ってくれりゃいいんですけどね(´・ω・｀)
どうにもリアルタイムで追いかけてstableなポイントをメモしとかないとダメっぽいですね。
ありがとうございました。
0387デフォルトの名無しさん2011/02/02(水) 19:44:38
git-svn で元リポジトリの構造が svn/trunk だったのから svn/proj/trunk みたいに
階層構造が変化した場合って git svn clone からやり直さなきゃダメ？
0388デフォルトの名無しさん2011/02/02(水) 23:14:08
同じような状況で、.git/config だけ書き換えたら大丈夫だろうと思って
やったらダメだったことはある。
0389デフォルトの名無しさん2011/02/03(木) 00:08:21
>>388 ﾅｶｰﾏ
なんか git svn relocate svn/trunk svn/proj/trunk みたいなのがあるんじゃないかと
思って調べても全然見つからないのよね。
0390デフォルトの名無しさん2011/02/03(木) 00:29:59
それは git svn が svn switch --relocate をちゃんとしてくれないってこと？
0391デフォルトの名無しさん2011/02/03(木) 01:41:56
git svn はclone元のsvnリポジトリの構造変化に追従してくれないんじゃない？ってこと。
0392デフォルトの名無しさん2011/02/03(木) 01:58:57
いや、svnだってcheckout元のsvnリポジトリの構造変化には追従しないよ。
だから svn switch --relocate があるでしょ？
git svn は git svn switch --relocate を受け付けてくれないの？と聞いた
つもりだったんだけど？
0393デフォルトの名無しさん2011/02/03(木) 11:07:40
>>392
試してみた。
>いや、svnだってcheckout元のsvnリポジトリの構造変化には追従しないよ。
あらホント。move を追跡してくれるものと思い込んでた。

で、git svn switch は git svn switch 自体が無いみたいですね。
0394デフォルトの名無しさん2011/02/03(木) 11:16:40
やりかた見つけた＆試して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 が変化検出できないっぽい。
0395デフォルトの名無しさん2011/02/03(木) 16:01:23
なんというバッドノウハウ
でもメモっとこう
0396デフォルトの名無しさん2011/02/03(木) 17:38:43
そのうち git svn switch が実装されると信じて
0397デフォルトの名無しさん2011/02/09(水) 18:55:07
TortoiseGitでプロジェクトの管理を行っていますが、
一度clone等でデータを取ってくると、フォルダを消そうとしても
消せなくなってしまいます。
調べてみるとTGitCache.exeというプログラムがプロジェクトの
フォルダを使用しているようです。なのでフォルダを消す時は
TGitCache.exeを終了させてから削除しています。

他のユーザーの方も同じ現象が起きるなどしていませんか？
0398デフォルトの名無しさん2011/02/09(水) 19:14:30
質問です。

「入門Git」を読み始めたのですが、
シェルのエンコーディングが　utf-8
ソースコードのエンコーディングが　euc-jp
という環境で、
シェルから以下のコマンドを実行すると、
ソースコードの日本語コメント部分が化けてしまいます。
　　git diff
　　git add -p

対応方法があれば教えていただけないでしょうか?

logについては、
.gitconfigに
以下を設定をすることでうまくいっています。
　　commitencoding = euc-jp
　　logoutputencoding = utf-8

また、git diffについては、
　　git diff | nkf -w -Lu | less
とかすれば、とりあえず回避はできるのですが...

＃自分の環境は utf-8 で、
＃ソースコードとログは euc-jp になっているため、
＃こんなことで悩んでおります。
0399デフォルトの名無しさん2011/02/09(水) 19:22:43
aliasで!shとか使えば？
0400デフォルトの名無しさん2011/02/09(水) 20:45:18
>>398
その設定だと、コミットログが化け化けで入っていないか？
コンソールでしか作業をしないのなら、ロケールと端末をEUC-JPに変えるという発想は？
LANGだけでロケール変わらないか？
0401デフォルトの名無しさん2011/02/09(水) 21:12:26
漏れならソースコードをUTF-8にするの一択
04023982011/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はシステムデフォルトにしたという経緯があります。

自宅の環境ではないので、明日、もういちどそのあたりを確認してみようと思います。
0403デフォルトの名無しさん2011/02/09(水) 21:50:06
>>402
ここをよく読むとだな
http://www.kernel.org/pub/software/scm/git/docs/git-commit-tree.html
logoutputencodingは設定してなくてもUTF-8だそうだ。
emacsがeuc-jpだとcommitencodingがeuc-jpで正解のようだ。
04043982011/02/09(水) 22:00:16
>>401
> 漏れならソースコードをUTF-8にするの一択

自宅ではそうします！
0405デフォルトの名無しさん2011/02/09(水) 22:00:44
>>402
>>399は
https://git.wiki.kernel.org/index.php/Aliases
でnkf入りのdiffコマンドを作る
04063982011/02/09(水) 22:04:50
>>403
読んでみます！
ありがとうございます。

>>405
いろいろ情報ありがとうございます。
そちらも読ませていただきます！
0407デフォルトの名無しさん2011/02/09(水) 22:11:46
重要な１行があった
> If you do not have this configuration variable, the value of i18n.commitencoding is used instead.
logoutputencodingが設定していないとcommitencodingが使われるってことか。
0408デフォルトの名無しさん2011/02/10(木) 00:09:14
最近発見した方法
euc-jp,shift_jis,utf-8等が混在したプロジェクトでも(たぶん)大丈夫
例はCソースを扱う場合(*.c、*.h、*.txt)
フィルタはnkfでなくてもいい
cygwin上のgitでも同様

1) .gitattributes に以下の行を追加

*.c diff=nkf
*.h diff=nkf
*.txt diff=nkf

2) .gitconfig に以下の行を追加

[diff "nkf"]
textconv = nkf -w

同じ要領でblame等もフィルタすると幸せになれるかもしれない
04093982011/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で試す→うまくいく
04103982011/02/10(木) 23:41:08
あとは、git add -pしたときに、
ソースコードの日本語コメント部分が化ける問題が残っている
・・・のは残っているんですが、
なぜかWindowsXPからputtyを端末にして接続すると化けませんでした。

表にすると(たしか)以下のような感じだったと思います。
「端末」の設定さえしっかりしていれば、
git add -pのときの出力は、
うまいことgitがやってくれているんでしょうか?

また来週みてみます。
長々とすみません。

---------------------------------------------------------
　　　　　　　　　　　　diff.textconvの設定あり　設定なし
---------------------------------------------------------
Linuxの端末でgit diff　　　　○　　　　　　　　　　×
Linuxの端末でgit add -p　　　×　　　　　　　　　　×
---------------------------------------------------------
WinのPuttyで git diff　　　　○　　　　　　　　　　×
WinのPuttyで git add -p　　　○　　　　　　　　　　○
---------------------------------------------------------

　○: 文字化けしない　×: 文字化けする
0411デフォルトの名無しさん2011/02/11(金) 00:01:52
windowsすげー
0412デフォルトの名無しさん2011/02/11(金) 00:26:54
>>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"
0413デフォルトの名無しさん2011/02/14(月) 17:07:01
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0414デフォルトの名無しさん2011/02/14(月) 19:51:28
ソースコード管理を行う分散型バージョン管理システム、Bazaarについて語ろう。

■本家
http://bazaar.canonical.com/en/
■チュートリアル
http://doc.bazaar.canonical.com/latest/ja/mini-tutorial/index.html
■ユーザーズガイド
http://doc.bazaar.canonical.com/latest/ja/user-guide/index.html

■前スレ
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
0415デフォルトの名無しさん2011/02/14(月) 20:23:08
どうして、京都大学霊長類研究所は、アイちゃんの、
スレ乱立を見過ごしてるの？

独自の板立ててそっちで実験するとかできないの？
いまどき、主婦だって専用の板ぐらい立てられるぞ。

「関係者以外は書きこまないで下さい。」とか、何
お前らがエラソーに仕切ってんだよ、ハゲ！

糞スレをあちこちにポンポン乱立されちゃ迷惑なんだよ。
ったく、京都大学霊長類研究所は能無しの集まりかよ！
0416デフォルトの名無しさん2011/02/14(月) 20:50:31
これが、コピペにマジレスの実物か
0417デフォルトの名無しさん2011/02/14(月) 22:10:48
ttp://www.google.co.jp/search?hl=ja&biw=909&bih=664&q=%22%E3%81%A9%E3%81%86%E3%81%97%E3%81%A6%E3%80%81%E4%BA%AC%E9%83%BD%E5%A4%A7%E5%AD%A6%E9%9C%8A%E9%95%B7%E9%A1%9E%E7%A0%94%E7%A9%B6%E6%89%80%E3%81%AF%22&aq=f&aqi=&aql=&oq=
まさにコピペにマジレス
0418デフォルトの名無しさん2011/02/14(月) 23:25:17
Bazaarのドキュメント - 変化に強いバージョン管理システム
http://doc.bazaar.canonical.com/ja/
0419デフォルトの名無しさん2011/02/14(月) 23:42:28
何でbzr貼るん？
0420デフォルトの名無しさん2011/02/15(火) 00:08:58
http://hibari.2ch.net/test/read.cgi/tech/1265951333/999

馬鹿が悪乗りしてるから
0421デフォルトの名無しさん2011/02/15(火) 02:30:28
【bzr】Bazaarでバージョン管理 Rev 3
http://hibari.2ch.net/test/read.cgi/tech/1297704483/
0422デフォルトの名無しさん2011/02/16(水) 11:20:36
GitGitにしてやんよ！
0423デフォルトの名無しさん2011/02/16(水) 11:47:47
GitGitにしてください
http://wiki.bazaar.canonical.com/BzrVsGit
0424デフォルトの名無しさん2011/02/16(水) 11:50:09
ここも
http://standing-shoebill.appspot.com/bzr-migration-docs/ja/survival/bzr-for-git-users.html
http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
0425デフォルトの名無しさん2011/02/16(水) 11:51:02
うむ、InternalServerError出たからマジで驚いたｗ
リロードしたら直ったけど、This page is obsolete! じゃん！
0426デフォルトの名無しさん2011/02/16(水) 12:53:39
>>424
> Gitユーザは、リベースの難しさや、多くのBazaarユーザのやり方に対する非難めいた態度にイライラするかもしれません。 Bazaarでは、コミットは「重たく」、ブランチもとても「重たい」ものです。
0427デフォルトの名無しさん2011/02/16(水) 21:31:26
そこ翻訳ちょっとへんだよな
0428デフォルトの名無しさん2011/02/16(水) 21:48:51
> 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.
0429デフォルトの名無しさん2011/02/16(水) 22:14:04
> Gitユーザは、リベースの難しさ、そしてやり方についての多くのBazaarユーザのとても非難めいた態度に、
イライラするかもしれません。
0430デフォルトの名無しさん2011/02/19(土) 13:11:26
GITはいつになったら日本語ファイル名に対応するんだ？

昔から言われてるのに全く対応されない。

開発者不足のダメソフトってのが伝わってくる。

こんなんじゃ、他にもバグ満載に決まってるだろ。

怖くて使えねーｗｗｗｗｗ
0431デフォルトの名無しさん2011/02/19(土) 13:21:19
ユーザの多くがプログラマーなら、そんなもの必要だとは思ってない。
0432デフォルトの名無しさん2011/02/19(土) 13:25:42
>>430
Mercurial追い出されて今度はこっちですか？
具体的にどこがどう対応していないのですか？
0433デフォルトの名無しさん2011/02/19(土) 15:17:57
GITでは、WindowsとLinuxの相互運用で日本語ファイル名が文字化けする。

実用に使えない糞ソフト。
0434デフォルトの名無しさん2011/02/19(土) 15:21:37
「文字化け」という言葉を使っている時点で馬鹿丸出し
0435デフォルトの名無しさん2011/02/19(土) 15:24:44
「実用に使えない」とか日本語不自由な人間が日本語ファイル名なんか気にすんなよ
0436デフォルトの名無しさん2011/02/19(土) 16:42:10
GitもTortoiseGitも使ってるけど
2010年代にもなってダメ字に引っかかる仕様なのはアホとしか言いようがないな
対応してくれた人もいるわけだし(古いバージョンしかないけどorz)さっさ取り込んでやれよ
0437デフォルトの名無しさん2011/02/19(土) 16:44:00
機能面で反論できないところを見ると、やはりGITが糞ソフトであることは間違いないようだ。
0438デフォルトの名無しさん2011/02/19(土) 16:44:00
Gitの時代になっても日本人は英語コミュニティに及び腰、だろ?
0439デフォルトの名無しさん2011/02/19(土) 16:54:38
2010年代にもなってWindowsがCP932なのがアホ
CP65001になればみんなハッピー
0440デフォルトの名無しさん2011/02/19(土) 16:57:45
TortoiseGitで日本語ファイル名を使う需要が本当にあるのか。
地雷があるのが分かっているのに。
でも、UTF-8の需要は海外の方が大きい気がする。
0441デフォルトの名無しさん2011/02/19(土) 17:07:01
メジャーなOSで普通にファイル名に利用出来る文字で文字化けが起こるソフトが糞。

そんなソフト使いものにならない。
0442デフォルトの名無しさん2011/02/19(土) 17:08:37
どんな文字でもどんな長さでもファイル名に使えると思ってる世代は幸せだね。
ファイル名なんてVCSの極々々々々々一部だよ。
0443デフォルトの名無しさん2011/02/19(土) 17:17:18
git config --global core.quotepath false を知らないアホがいると聞いて
0444デフォルトの名無しさん2011/02/19(土) 17:19:04
>>443
だめだよ、余計なこと教えちゃ
0445デフォルトの名無しさん2011/02/19(土) 17:26:00
quotepathやログを含め、Gitの多言語対応はしっかりしている。
0446デフォルトの名無しさん2011/02/19(土) 19:13:36
GITはクロスプラットフォームで文字化けが発生してしまうから使いものにならない。

この開発者は文字コードを理解してないド素人なんだろうな。

こんなスキルの低い連中の作ったソフトなんて怖くて使えない。

どうせファイルとかも消えちゃうんだろ。
0447デフォルトの名無しさん2011/02/19(土) 19:15:17
>>446
じゃあそれでいいです

はいほかの方どうぞ
0448デフォルトの名無しさん2011/02/19(土) 19:19:05
うむ、>>446に賛同しておこう
では次の話題に
0449デフォルトの名無しさん2011/02/19(土) 19:26:55
文字化けの話題はもう>>443で解決してる
次の話題どうぞ
0450デフォルトの名無しさん2011/02/19(土) 19:28:41
>>449はクロスプラットフォームでの問題を理解出来ないバカ。
0451デフォルトの名無しさん2011/02/19(土) 19:36:27
cygwinも使えない馬鹿がいると聞いて
0452デフォルトの名無しさん2011/02/19(土) 19:38:53
cygwinを使わないと日本語環境でまともに利用できないバカなソフトがあると聞いて
0453デフォルトの名無しさん2011/02/19(土) 19:40:10
UIがcygwin環境に縛られる時点で、Windowsソフトとして終わってる。
0454デフォルトの名無しさん2011/02/19(土) 19:41:07
そもそもWindowsソフトじゃないし。
0455デフォルトの名無しさん2011/02/19(土) 19:44:43.88
やっぱりGITはWindows未対応なんだ。

確かにあんなに文字化けが発生する状態でWindows対応だなんて恥ずかしくて言えないわな。
0456デフォルトの名無しさん2011/02/19(土) 19:46:38.03
どっちかっつーといつまでもUTF8ロケール用意できないWindowsが終わってるのでは

WindowsがいつまでもCP932みたいなレガシーなコードページを使わせるとしても
せめてMSVCランタイムのC/C++ロケールでUTF-8をサポートできていれば
マシかもしれないが、それも無い
だからWindowsでは、OS内部ではUnicodeのくせに、それをprintf()などで
標準出力に出力することすらできない
0457デフォルトの名無しさん2011/02/19(土) 19:48:50.21
Windows批判はスレ違いです。
0458デフォルトの名無しさん2011/02/19(土) 19:50:47.29
え、Windows って GIT 未対応なの?
0459デフォルトの名無しさん2011/02/19(土) 19:52:32.30
クスクス…いまどきGitが使えない環境なんて遅れてるｗ
0460デフォルトの名無しさん2011/02/19(土) 19:54:36.33
　//／／／／／／,　''"　 　 ヽﾐ川川
　|//／／／／,　'"　　　　　　　',川川
　川/////,　'",,,,,,,,,,,,,,,,　　　　r''"',川||
　川f 川f´　　　　　　　　　　 ,ィ::ﾗ',川　　やだっ…私のバージョン管理システム、日本語ファイル名使えない…？
　川ﾍ　 |　　 　弋て::>　　　　￣ 　',ﾘ
　 川 ﾍ.__　　　　　　　　　　 ヽ　／７!　　（２９歳 Aさんの場合）
　　川川 ﾍ　　　　 _,.　'-‐''"´y'　 //
　　 川川ﾘﾍ　,　'´　　　__,,,／　 / /
　 　川川川|/　　　'"´　　　,　'´ /||
　　 川川川|　　　　　　　　　　 /川
0461デフォルトの名無しさん2011/02/19(土) 19:57:12.19
えっ、日本語ってGitに対応してないのｗｗｗｗ
0462デフォルトの名無しさん2011/02/19(土) 19:58:34.73
>>461
EUC-JPもUTF-8も対応しています。cygwinでも。
0463デフォルトの名無しさん2011/02/19(土) 20:07:37.57
>>462
おちつけ
0464デフォルトの名無しさん2011/02/19(土) 20:08:16.80
開発陣を無能だと思うんなら有能な君がパッチを送ればいいじゃないか
0465デフォルトの名無しさん2011/02/19(土) 20:14:30.50
タグを見るんだ
http://repo.or.cz/w/git.git
あとは分かるな？
0466デフォルトの名無しさん2011/02/19(土) 20:17:44.80
>>463
当然ISO-2022-JPも対応しています。cygwinは分からん。
0467デフォルトの名無しさん2011/02/19(土) 20:22:21.82
Windowsで使えないなんて信じられないニダ！
我が国の母国語が化けるとかクソニダ！
早く使えるようにしろ！！！　謝罪しろ！　賠償しろ！！！

どっかの国の人みたいなこと言ってんなよ、、、
0468デフォルトの名無しさん2011/02/19(土) 21:37:46.55
単にGITが日本では実用にならない糞ソフトってことだよ。謝罪も賠償も必要ない。
0469デフォルトの名無しさん2011/02/19(土) 22:30:51.44
と言うことにしたいのですね？
0470デフォルトの名無しさん2011/02/19(土) 22:34:27.75
>>468
GITとやらが糞ソフトならLINUXは何ソフト？
0471デフォルトの名無しさん2011/02/19(土) 22:35:24.29
比較的有用なOS
0472デフォルトの名無しさん2011/02/19(土) 23:51:22.82
git grep って
現在いるフォルダとサブフォルダを検索対象にするけど
トップディレクトリ(.gitのあるとこ)以下を検索したいときは
どうすれバインダー
おしえてケロリン
0473デフォルトの名無しさん2011/02/20(日) 01:09:11.88
git help grep

--max-depth <depth>
0474デフォルトの名無しさん2011/02/20(日) 12:38:06.45
>>471
それじゃWINDOWSは？
0475デフォルトの名無しさん2011/02/20(日) 13:10:54.21
比較的有用なOS
0476デフォルトの名無しさん2011/02/20(日) 18:06:55.87
比較対象は秘密だけどな
0477デフォルトの名無しさん2011/02/20(日) 18:29:21.33
>>476
Minix
0478デフォルトの名無しさん2011/02/20(日) 20:07:45.05
>>476
Winが公式に認める比較対象は、旧バージョンのWinのみ。
0479デフォルトの名無しさん2011/02/21(月) 17:05:32.87
共有リポジトリサーバで、ブランチ毎に clone/push/pull するにはどうすればいいんですかね？
そもそも、ブランチ毎にリポジトリサーバ立てるもの？
0480デフォルトの名無しさん2011/02/21(月) 22:12:01.03
んなこたーない。指定できるよ。
0481デフォルトの名無しさん2011/02/22(火) 02:32:16.96
もうちょっとヒントだしてあげてもいいと思うけど。

>>479
cloneはブランチ毎にはできないはず。git clone URL でぜんぶまとめてとってくる。
pushとpullはブランチ毎にできる。
git co -b dev origin/dev
git commit
git push origin dev

まちがってたらごめん。自分も勉強中なんだ。
0482デフォルトの名無しさん2011/02/22(火) 09:28:51.24
ありがとうございます。
なるほど。
ということは、別ブランチにpushしたものをcloneすると、
そのブランチもついてくるって感じですかね。
とにもかくにも、上記試してみます。
0483デフォルトの名無しさん2011/02/22(火) 10:46:46.76
自分も似たようなことしたくて調べてみたら
使いたいのはサブモジュールなんだな、とわかったんだけど、なにこの魔境… orz
サブモジュールの中に居るかどうかで、コマンド体系を切り替えないといけないのは
なんの苦行なんだろう。とても魅力的な機能なのになぁ。
どうしてこうなった…。
0484デフォルトの名無しさん2011/02/22(火) 13:09:01.34
サブモジュールはどうしても必要に迫られない限り、やりたくないなぁ。
ありゃキツいよ…
0485デフォルトの名無しさん2011/02/22(火) 22:02:51.69
サブモジュールがいやならrepoを使えばいいじゃない。
0486デフォルトの名無しさん2011/02/22(火) 23:47:55.59
>>485
おー、これ良さそうだね！ 教えてくれてありがとう！
0487デフォルトの名無しさん2011/02/23(水) 21:58:26.22
オブジェクトは共用(bareでも可)で、複数のディレクトリで各ブランチをチェックアウトしたままにしておきたいんだがどうすればいい?

単一のリポジトリにてcheckoutでブランチを切り替えると、autoconf絡みで怒涛のようにfull rebuild状態になっていやん。
0488デフォルトの名無しさん2011/02/23(水) 22:49:06.02
>>487
オブジェクト共用って、ディスクスペースを節約したいってこと？
cloneのオプションでハードリンクにすることも出来るけど、そういうことではなく？
0489デフォルトの名無しさん2011/02/23(水) 23:13:58.16
>>488
Unixだと問題ないのかな? win だと無理?
git gc のことを考えなければ、単純に git を騙して共用させられればいけるような気もするが…
0490デフォルトの名無しさん2011/02/24(木) 07:49:44.01
git-new-workdir
0491デフォルトの名無しさん2011/02/24(木) 22:47:25.39
msysGit-netinstall-1.7.4-preview20110204.exeでGitをインストールしようとしたら
GPLed program for Windows NT/2000/XP/Vista/6 and Windows 95/98/ME は動作を停止しました
って出る。なんで？
0492デフォルトの名無しさん2011/02/26(土) 15:34:40.78
質問させてください。

サーバ管理されているgitリポジトリがあって
自分の作業とは関係なくコミットされていきます。

自分しか利用しないコード(俺コード)をどこかに保存しておいて
好きなときに任意のトピックブランチに適用させたり元に戻したりしたい場合､
どのような手順で行うのが適切でしょうか。

実戦経験ほぼ0なのですが､git本を読んでみて思い浮かんだ方法は
たとえば以下のような方法です｡

1. masterから俺コードを追加したbranch(俺ブランチ)を作っておいて、
トピックブランチにマージする。
俺ブランチがマージできなくなったらその都度rebaseしておく。
1. サーバが更新されるたびに俺ブランチにmasterをマージし、
トピックブランチは俺ブランチから派生する。
2. 俺コードをstashで保存しておき、トピックブランチに適用する。

よろしくお願いします｡
04934922011/02/26(土) 15:38:21.40
俺様がよくやる方法みたいな情報も大歓迎です｡

よろしくお願いします｡
0494デフォルトの名無しさん2011/02/26(土) 15:44:37.68
>>492
ほんの軽い差分ならstash、いくつかのコミットになるなら俺ブランチでrebase、
って感じかな。
0495デフォルトの名無しさん2011/02/26(土) 15:59:29.46
>>494
早速のレスありがとうございます！

>いくつかのコミットになるなら

どんどん進化していくような俺コードだとstashは不適切という訳ですね｡
φ(..)メモメモ
0496デフォルトの名無しさん2011/02/26(土) 22:26:22.55
>>495
どっかの公開repoに俺修正で追っかけてくのは、Git使うと基本作業みたいなものなので、
mergeして追随するパターン、rebaseするパターン、とりあえずstash、
それぞれじっくりやってみたらいいと思うよ。
0497デフォルトの名無しさん2011/02/26(土) 23:35:24.82
>496
レスありがとうございます！

> それぞれじっくりやってみたらいいと思うよ。

merge、rebase、stashそれぞれ使いどころがあるってことですね。
φ(..)メモメモ
0498デフォルトの名無しさん2011/02/27(日) 01:49:19.63
>492
2以外はだいたい一緒
stashは使いどころをまだよく理解していないもんで
0499デフォルトの名無しさん2011/02/27(日) 02:26:42.81
>>492
俺コードをguiltで管理する方法もある
0500デフォルトの名無しさん2011/02/27(日) 12:49:05.29
>>498>>499
レスありがとうございます！

> 2以外はだいたい一緒

あ、1,2,3にしたつもりが1,1,2になってますね>_<

> 俺コードをguiltで管理

そんな方法もあるんですね｡

ざっと調べてみましたが、stashと異なるのは､
・gitのコミットとして管理される
・適用したquiltを元に戻すのが簡単
といったところでしょうか｡
0501デフォルトの名無しさん2011/03/01(火) 23:30:46.34
git svn fetchでRefspec glob conflictってのがたくさん出ますが、どういう意味なんでしょう？

W: Refspec glob conflict (ref: refs/remotes/1.5):
expected path: branches/1.5
real path: branches/releases/1.5
Continuing ahead with branches/releases/1.5
W: Refspec glob conflict (ref: refs/remotes/1.6):
expected path: branches/1.6
real path: branches/releases/1.6
Continuing ahead with branches/releases/1.6
W: Refspec glob conflict (ref: refs/remotes/1.7):
expected path: branches/1.7
real path: branches/releases/1.7
Continuing ahead with branches/releases/1.7
W: Refspec glob conflict (ref: refs/remotes/git-svn):
expected path: branches/git-svn
real path:
Continuing ahead with
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: branches/trunk
real path: trunk
Continuing ahead with trunk
0502デフォルトの名無しさん2011/03/06(日) 07:12:59.56
>>501
何かおかしいみたいだけど、どういう設定でgit-svn initしたのかな？
0503デフォルトの名無しさん2011/03/06(日) 18:05:29.84
質問です。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
0504デフォルトの名無しさん2011/03/07(月) 04:02:31.92
>>503
LinuxとOSXで試して分かった。
同じディレクトリに大文字、小文字だけ違うファイルがあるんだけど
OSXはそれを同じファイルとして扱うから先に作られたファイルが上書きされるんだ。
0505デフォルトの名無しさん2011/03/07(月) 09:16:41.48
となると、OSX的にはcase sensitiveなディスクイメージを作って、それを
マウントして、その中で作業することになりそうだな。
起動ボリューム自体をcase sensitiveにすると、動かなくなる市販アプリが
あったりするのでお勧めしない。

0506デフォルトの名無しさん2011/03/07(月) 10:35:15.55
>>504
俺もそれバグかと思った。checkoutでも怒られることあるよ
0507デフォルトの名無しさん2011/03/07(月) 10:44:22.92
ところで大文字小文字の違いだけでファイルを分けるのはどうなんだろう
よくやることなの？
作法云々もあるけど非常に管理しにくくなると思うんだが
0508デフォルトの名無しさん2011/03/07(月) 11:02:20.08
>>507
微妙な違いだと目視で間違えそうだし、HFSみたいなファイルシステムのことを考えるなら
あまりよくないだろうね。
0509デフォルトの名無しさん2011/03/07(月) 11:15:23.38
カビの生えたソフトのtar玉(.tar.Zだったりする)の中に
makefileとMakefileが入っていて、脳裏でプツンという音が
聞こえた遠い日。
0510デフォルトの名無しさん2011/03/07(月) 11:17:51.63
ああ
昔はよくあったな
同じファイルなのに
起動される名前が違うだけで
挙動が変わるのとか
0511デフォルトの名無しさん2011/03/07(月) 11:39:42.49
呼ばれる名前で挙動が変わる？　Gitはそうだよｗ
シェルスクリプト以外はほぼ全部ハードリンクｗｗｗ
0512デフォルトの名無しさん2011/03/07(月) 13:12:56.37
え・・・なんで一人でテンション上がってんのこの人
0513デフォルトの名無しさん2011/03/07(月) 16:26:20.91
すまん、寝てないんだ
05145012011/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/*
0515デフォルトの名無しさん2011/03/08(火) 01:24:12.96
OSはwindows7
管理するものはC++のソース、
利用人数は１人、
として使うバージョン管理システムで
Gitはオススメできますか？
もしオススメできないとしたら他にはどのような選択肢がありますか？
0516デフォルトの名無しさん2011/03/08(火) 01:27:00.25
gitマジおぬぬめ
0517デフォルトの名無しさん2011/03/08(火) 02:16:48.91
hgがいいんでね？
0518デフォルトの名無しさん2011/03/08(火) 03:10:56.55
間を取って、hgitおすすめ。
0519デフォルトの名無しさん2011/03/08(火) 03:16:16.20
LLじゃなくCで実装されてるなら何でも良いよん
0520デフォルトの名無しさん2011/03/08(火) 03:23:00.66
>>515
日本語のファイル名をつけたいなら、日本語WindowsでGitは化けるらしいよ。
UTF-8に対応したCygwinとかいうのなら、大丈夫らしいけど。
0521515 2011/03/08(火) 16:56:55.40
みなさんありがとうございます。
とりあえずgitの導入に挑戦してみようかと思います。
05225032011/03/13(日) 18:59:49.67
遅くなりましたが>>503です。
皆さんの言う通りファイルシステムの違いによるものでした。
ディスクイメージを作ってそこにcase-sensitiveなファイルシステムを
作ってみたところ、正しくチェックアウトできました。
ありがとうございます。
0523デフォルトの名無しさん2011/03/14(月) 21:30:25.68
会社はSubversionなんだけど、
自分だけでもGit使ってみようと思って、
さっきgit clone仕掛けて帰ってきた。
明日 出社したら終わってるかな?
0524デフォルトの名無しさん2011/03/15(火) 02:03:33.89
別に前revision変換しなくてもよくね？
0525デフォルトの名無しさん2011/03/15(火) 20:35:27.20
>>524
>>523ですが、会社行ったら
Out of memory!
になって死んでました。

とりあえずブランチだのタグだのは諦めて、
自分の担当パートだけ、
git cloneしてみました。

これであとはgitの使い方に慣れて行けば、
あれやこれやの変更をパッチ形式で持ち続ける必要なくなるかな。
svnのブランチやら、他のツリーへのマージは
結局パッチにしてそれをあててからリリースになるんだろうけど。
0526デフォルトの名無しさん2011/03/15(火) 20:48:14.12
>>525
git svn clone だよね？
git svn dcommit で Subversion 側にコミットもできるよ。
0527デフォルトの名無しさん2011/03/15(火) 20:50:02.98
ああごめん。
一部だけ持ってきたって話なのか。無視してくれ。
0528デフォルトの名無しさん2011/03/15(火) 22:58:20.64
>>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
0529デフォルトの名無しさん2011/03/15(火) 23:04:25.71
〜>>528のつづきです〜

・・・で、担当パートの変更は、
ブランチにもチェックインしないといけないんですが、
そういうときに、本当なら
　　git svn clone repo
してあれば、もっとうまいことできるってことなんですよね？

実際のところ、
（branchでは無く何故か）repoをコピーして作ったリポジトリもあったりして
そっちにもチェックインしないといけないので、
どっちにしてもパッチは使わざるを得ない感じです。

しばらく「trunk以外にはパッチ」対応しようと思いますが、
これじゃせっかくのコミットログが活かせなくて、めんどくさいですよね・・・
Gitはうまいことやってくれてるのになあorz
0530デフォルトの名無しさん2011/03/18(金) 00:53:39.82
msysgitでgit svn cloneしたリポジトリで、Linux上でgit svn fetchしたら
Byte order is not compatibleとか出て止まってしまいます
うまく使えるリポジトリもあるのですが

Index mismatch: f71ffe6d63dcbcae42984345c9f893cba4fc5591 != dafe4d76323aa24779a980b578625ca8a7972846
rereading 7b2b822d7b55
Byte order is not compatible at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 380, at /usr/share/perl/5.10.1/Memoize/Storable.pm line 21
0531デフォルトの名無しさん2011/03/18(金) 19:44:19.35
で？
0532デフォルトの名無しさん2011/03/29(火) 17:47:54.75
$ git init
$ git checkout -b dev-branch
fatal: Not a valid object name: 'master'.

why???????

$ git branch
$

たしかにmasterブランチはないけど
1度でもコミットしないとブランチは作れないの？(´･ω･`)
0533デフォルトの名無しさん2011/03/29(火) 18:00:45.59
ブランチ切る元がないんだから当たり前に見えるな
0534デフォルトの名無しさん2011/03/29(火) 18:09:31.45
幹がなけりゃ枝も生えん
0535デフォルトの名無しさん2011/03/29(火) 18:19:32.52
え、でもファイルがないとコミットできないんですよ(´･ω･`)
リポジトリを作ってすぐにブランチを切りたかったら空のファイルをコミットして、ブランチ切るのが作法なんでしょうか
0536デフォルトの名無しさん2011/03/29(火) 18:23:52.79
つまり、空のディレクトリで git init しましたってことなん？
そして、空のまま git checkout しようとしたってことなん？



頭が空の人間なん？
0537デフォルトの名無しさん2011/03/29(火) 18:26:23.54
>>535
ブランチの名前は後から自由に変えられる
0538デフォルトの名無しさん2011/03/29(火) 18:46:42.30
echo "hoge" > hoge.txt
git init
git add .
git commit -m 'initial commit'
git branch -m dev-branch
0539デフォルトの名無しさん2011/03/30(水) 04:22:50.15
>>535
Gitでは　ブランチ＝コミットに対する別名　なので、
ブランチを"切る" というような動詞から連想するようなことは起こっていない。

どうしてもやりたいなら、こうかな
git init
git symbolic-ref HEAD refs/heads/dev-branch
0540デフォルトの名無しさん2011/04/01(金) 01:09:49.43
特定のファイルの追加や削除の追跡をしたいのですがよい方法はないですか？
知りたいのはどのリビジョンで追加や削除したのかという情報です
git blame でファイルを指定したらバイナリファイルのせいか画面がぐちゃぐちゃになってひどいことになりました
git blameはソースの変更を追いかけるものだからバイナリはお門違いなのでしょうけど
0541デフォルトの名無しさん2011/04/01(金) 01:18:25.90
普通にi git log filename じゃダメなん？
0542デフォルトの名無しさん2011/04/01(金) 16:38:06.84
>>536
そうですね空のままは変ですね

>>537-539
あーなるほど
ブランチやタグはコミットに名前をつけているんだということをわかったつもりだったのに理解していませんでした
コミットした後からでこちらの想定の使い方的に問題ないようでした
ありがとうございました
0543デフォルトの名無しさん2011/04/07(木) 21:40:35.74
現在のファイルにおいて、
その行がいつ変更・追加されたかはgit blameでわかる
・・・と本を読んで知りました。
逆に、昔あったはずの行が削除されたのがいつなのか
を知る方法はありますか？

git log -p <filename> | grep -E '^- 昔あったはずの行'
みたいな感じで探して行くのが良いでしょうか？

git logの-pオプションで表示されるパッチ部分に
git logの--grepオプションが適用されてくれれば、
もう少し手間が省けそうと思って試してみましたが、
そんな風には動いてくれませんでした。
0544デフォルトの名無しさん2011/04/07(木) 23:09:12.42
>>543
俺もそういう時 git log -p してた。何か方法があるなら知りたいな。
0545デフォルトの名無しさん2011/04/08(金) 00:40:04.26
>>543
git log -S"〈文字列〉"

で、〈文字列〉が追加または削除された履歴を確認できる
0546デフォルトの名無しさん2011/04/08(金) 06:01:22.89
そんな方法があるんですね！
ちょっと調べてみます。ありがとうございました。
0547デフォルトの名無しさん2011/04/08(金) 22:39:43.00
>>545
うわこれめっちゃ便利だ！！！
ありがとう！！！
0548デフォルトの名無しさん2011/04/09(土) 06:49:06.41
githubでpullリクエストもらった時、複数のコミットが含まれてるのの１つだけマージするとか可能でしょうか？
0549デフォルトの名無しさん2011/04/09(土) 07:31:38.51
>>548
途中までOKなのなら その位置を指定してマージでいけるけど、歯抜けだと cherry-pick ですな。
ただし、つまみ食いしても問題のないパッチシリーズじゃないと、おかしなことに。

もしpullリクエストしてる側がまるごと取り込んで欲しいと考えてるようであれば、
まるごとのマージは出来ない理由を示して、惜しいのであれば一部修正してもらったら
良いのではないでしょうか。そしたらまるっとマージしてお互いにハッピー。
0550デフォルトの名無しさん2011/04/09(土) 16:52:11.50
>>549
ありがとうございます、途中までは採用したいので、位置指定するマージのやりかたを調べてみます。
0551デフォルトの名無しさん2011/04/13(水) 18:55:59.16
全ブランチにmasterの変更をマージする方法はありますか?
いまのところ、
git branchでブランチのリストを表示させて、それを見てから、

　for i in ブランチ名1, 2, 3, ...
　do
　　git checkout $i
　　git merge master
　done

みたいにしてやっています。

もっと普通はこういうふうにやる、
というのがあれば、教えていただけませんか？
0552デフォルトの名無しさん2011/04/13(水) 19:35:25.42
rebase？
0553デフォルトの名無しさん2011/04/13(水) 19:41:20.13
>>551
hookかな
なんにしてもコンフリクトする可能性は考えないといけないが
0554デフォルトの名無しさん2011/04/14(木) 20:31:46.66
>>551です。
ありがとうございました。
たぶん私がまずやるべきはrebaseですね。
それをhookで自動化できるかも...
という感じでしょうか。
ちょっと調べてみます。

ありがとうございました。
0555デフォルトの名無しさん2011/04/15(金) 03:22:29.99
git-now！
0556デフォルトの名無しさん2011/04/16(土) 14:48:22.18
git nowってどの辺が便利なん？
0557デフォルトの名無しさん2011/04/16(土) 16:00:50.59
そんなコマンドないよ
0558デフォルトの名無しさん2011/04/16(土) 16:12:08.75
これかな？
http://d.hatena.ne.jp/sinsoku/20101208/1291770514
0559デフォルトの名無しさん2011/04/16(土) 16:47:06.76
stash知らないのか
0560デフォルトの名無しさん2011/04/18(月) 00:00:18.33
stashはうっかりstash clearとかしちゃうと大変だからコミットにしてるとかかな
俺はgit co -b tmpとかやってそっちに適当コミットを連発するのでgit-nowの便利さがわからん
0561デフォルトの名無しさん2011/04/18(月) 00:36:36.28
マジでログメッセージ入れる意味すら無いのなら commit -m wip とかでいい。
コミットにも日付含まれるってのに、ログメッセージ`date`にするのは意味不明。
さらにそれを意味のあるコマンドみたいにして命名するのも意味不明。
単に なう 言いたいだけちゃうん？
0562デフォルトの名無しさん2011/04/18(月) 00:54:15.20
いいんじゃね？リズムよく
git now
を使ってコミットすれば。
0563デフォルトの名無しさん2011/04/18(月) 08:17:18.20
俺もstash使わずたいていwip branchだな。
stashの概念がすごくad-hocな感じがする。
0564デフォルトの名無しさん2011/04/18(月) 08:49:12.98
git コマンド関係ない質問


github で公開されて週1くらいで誰か（1人）がコミットしてるプロジェクトがあります
issue にして誰かが直さなければならないだろうと思える細かい不良動作確認票が手元に30個くらいあります
全部登録すべきでしょうか？
ただでさえ出ない次バージョンが自分のせいでまた月単位で遅れるとかになったらめげるのですが

バージョン管理に関して、issue（やpull request）を出す側が気にする必要はありませんか？
0565デフォルトの名無しさん2011/04/18(月) 08:57:25.18
>>564
基本的には、個々の内容が妥当だという自信があるなら全て出すべき
たとえ自分の issue で 2 ページ埋まってもね
あれは known bugs な広報欄の役目も果たしてるから、不具合情報は共有されるべき

ただ
「issue は 0 にしてから次バージョン出すよぉ」
という潔癖さんが開発に混じってると問題はややこしく…ｗ
0566デフォルトの名無しさん2011/04/18(月) 08:59:55.48
出すのは勝手(むしろ歓迎)だが、出し方に気を付けないと、シカトされるか
BL入りだろう。相手も人間だ。つまり付随メッセージの書き方の問題。

ただ、Forkされたものにいちゃもんつける権利はFork元にはあるまい。
それがGithubってもんだと思う。なのでいじったものをForkしてコミットするのがよろしかと。
0567デフォルトの名無しさん2011/04/18(月) 09:24:42.35
たとえ嫌われても、差分コードを公開さえしてれば「いつのまにか」直ってることはよくある
ぶっちゃけ最終的には配布ライブラリ本体がよくなってれば万事OKなわけで

なお、文字エンコーディング関連の話を英語圏の作者さんに振るとたいてい嫌われる
テストに書いてある文字が読めないから何をやってるかわからないってさ
安心しろアスキー環境でも表示できるようバイナリリテラルで書いたから俺も読めん
0568デフォルトの名無しさん2011/04/18(月) 09:40:22.93
コード書くことで別の方法が思いついたりくっついたり分かれたり本質でないことに気づいたりするもんなので、
とりあえずpull requestする気でフォークしてコミットして公開するのがいいな
0569デフォルトの名無しさん2011/04/18(月) 19:00:41.40
BLってブラックリストのことか。普通にボーイズラブかと思ったよ。
0570デフォルトの名無しさん2011/04/18(月) 19:23:45.12
ボーイズラブでも普通に意味は通るな。





通んねえよ！
0571デフォルトの名無しさん2011/04/18(月) 20:23:52.97
てっきり次にこういうコマンド打つとこういう結果になるよって suggest してくれる機能かと思ってた > git now
0572デフォルトの名無しさん2011/04/19(火) 06:19:03.99
git-emacs で直接コミットメッセージ開き直して git commit -a --amend してくれる機能とかないの
M-x git-amend-commit は変な動作だし
0573デフォルトの名無しさん2011/04/19(火) 08:09:59.38
emacsよく知らないんだけど、いろいろあるみたいね
http://d.hatena.ne.jp/gom68/20090524/1243170341
0574デフォルトの名無しさん2011/04/19(火) 09:34:12.47
GNU EmacsはBazaarで開発されています。
Bazaarに切り替えて下さい。
0575デフォルトの名無しさん2011/04/19(火) 09:57:31.71
Mercurial チートシート http://troter.jp/mercurial-cheatsheet/#sec-1
＞1 はじめに
＞mercurialのチートシートがgithubに上がっていることに疑問を覚えないこと。
0576デフォルトの名無しさん2011/04/19(火) 23:39:07.16
>>574
とは言えemacs向けのbzrに特化したelが有る訳でも無し。
0577デフォルトの名無しさん2011/04/20(水) 14:01:19.09
GitHubで、いくつかプルリクエストしてメインに受け入れられました

…で、自分の公開エリアに残ったブランチどうしましょう
消しちゃっていい？
っていうかプルリクエストの数だけ加速度的に公開済みブランチが増えていく気がするんですが
皆さんどうやって管理してるもんなんでしょうか
0578デフォルトの名無しさん2011/04/20(水) 14:32:49.63
プルとプッシュがよくわかりません。

元のリモートリポリトジから最初にブランチをもってくるのがプル？？

で、ローカルでコミットしたあと元のリモートリポリトジに更新分を
送りつけるのがプッシュでいいのかな？
0579デフォルトの名無しさん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 に格納させます。」ってところでつまづいてます。
ここからどうしたらよいのか判りません
どなたかお力添えをお願いいたします
0580デフォルトの名無しさん2011/04/20(水) 14:56:10.10
viの使い方覚えましょう
それかデフォルトのエディタ変える
それかgit commit -m"aaa"ってやる
0581デフォルトの名無しさん2011/04/20(水) 15:05:32.27
>>578
カタカナだとわけわかめになる
pull は英単語
push も英単語
0582デフォルトの名無しさん2011/04/20(水) 15:09:30.06
>>577
orgissue12みたいなブランチ切ってpull requestするようにすれば後から見てもわかりやすい。
上流にマージされたなら消しても問題ないし残してても問題ないし好きにすればいいと思う。
0583デフォルトの名無しさん2011/04/20(水) 15:13:18.79
>>580
ありがとうございます！！！！これでコミットできました！
0584デフォルトの名無しさん2011/04/20(水) 15:19:39.49
pull は（サーバから）引っ張り込むんだよ
push は（サーバへ）押し出すんだよ

git pull はどちらかというとオリジナルとの同期コマンドだな…
0585デフォルトの名無しさん2011/04/20(水) 15:20:51.34
>>584サンキュ、理解できた！
0586デフォルトの名無しさん2011/04/20(水) 15:44:00.32
バージョン管理初心者はGitとSVNどっちがお勧めですか？
0587デフォルトの名無しさん2011/04/20(水) 15:49:27.45
>>586
Bazaar
0588デフォルトの名無しさん2011/04/20(水) 15:56:31.70
さすが兄者ｗ
0589デフォルトの名無しさん2011/04/20(水) 16:42:20.80
>>586
ＧｉｔとSVNという選択の仕方がすでに間違っている気がするｗ
Ｇｉｔと何かというならMercurialとかBazaarじゃね。
0590デフォルトの名無しさん2011/04/20(水) 16:46:18.50
gitとsvnの間で悩む時点で、分散かどうかなんてどうでもいいってことだろう。
だったらsvn一択じゃね？信頼感がぜんぜん違うよ！
0591デフォルトの名無しさん2011/04/20(水) 16:48:04.39
ひとまずDropbox使ってソースの置かれているディレクトリを対象に含めると良い。
何もせずにDropbox側のSVNでバージョン管理してくれる(20個程度だけど)。

ほとんど手間なしでよいから物臭なひとにはおすすめだ。
0592デフォルトの名無しさん2011/04/20(水) 16:48:36.16
用途を書いておきます
ファイルをバックアップするのが目的なのですが
例えば事故でファイルが消滅（他のファイルの内容で上書きとか、ファイル自体をゴミ箱にいれて戻せなくなった等）に備えて、バックアップを取ることです
0593デフォルトの名無しさん2011/04/20(水) 16:52:27.76
>>592
rsync
0594デフォルトの名無しさん2011/04/20(水) 16:53:26.13
ならsvnじゃね？
gitというか分散型だとリポジトリも同じ場所にできるから、ディレクトリごとごっそり消してしまったりしたときに弱い。

ただ、バックアップだけなら素直にOSのバックアップツールを使ったほうが小回りが効くような。
0595デフォルトの名無しさん2011/04/20(水) 17:04:02.50
>>592
その用途なら、俺もDropbox進めるわ。
1ファイルのサイズがでかいというなら外付けHDDと差分バックアップソフトかな。

どうしてもこの系統のソフトが使いたいならSubversion（winならTortiseSVN）で良いんじゃね。
0596デフォルトの名無しさん2011/04/20(水) 17:15:35.78
Dropboxって無料版だと30日で消されるんだって
0597デフォルトの名無しさん2011/04/20(水) 17:28:08.40
話の途中で申し訳ないが質問していいっすか？
Gitで良く使うコマンドって何？
0598デフォルトの名無しさん2011/04/20(水) 17:43:11.84
>>596
いや、普通に毎日ログインするだろｗ
てかおれの1年以上ほかしてたけど内容のこってたわ。
0599デフォルトの名無しさん2011/04/20(水) 18:30:34.11
>>598
古い変更履歴が消えるってことでしょ
0600デフォルトの名無しさん2011/04/20(水) 21:58:05.41
>>597
1. git rebase --continue
2. git checkout
3. git rebase (-i)

マジにネタレス。
0601デフォルトの名無しさん2011/04/20(水) 22:07:14.59
st(atus)だな

レスにマジネタ
0602デフォルトの名無しさん2011/04/20(水) 22:20:22.38
git remote update --prune もよく使う。
0603デフォルトの名無しさん2011/04/20(水) 22:23:24.15
たぶんgit grepとgit log foo/bar.txt
0604デフォルトの名無しさん2011/04/20(水) 22:35:55.03
リモートにまずブランチを先に作りたいと思うのですが、こんなやり方を見つけました。

http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/

これの
git push origin origin:refs/heads/ブランチ名

ってどう解釈すればいいのでしょう？　なぜref/headsなんてのが明示的に出て来るのか、
また、なぜこれでブランチを作る事になるのか分かりません。　

0605デフォルトの名無しさん2011/04/20(水) 23:10:52.89
>>604
git pushのmanページに詳しく書いてあるよ。

なぜpushで新規作成する時だけrefs/headsとフルで書かないといけないかというと、
フルで指定しないとどこに作っていいか曖昧だからだろう。まあ普通は refs/heads/
ですよね、ってことではあるけど、そうじゃない場合もありうるので。
0606デフォルトの名無しさん2011/04/20(水) 23:43:31.99
>>561
このwipってどういう意味なんだ
ぐぐったら一時的な(gitで言えばstash的な)作業やブランチ、コミットに使われているみたいだけど
ジャーゴン？
06076062011/04/20(水) 23:45:56.10
ふつうに英語の略語だったわ
wip=work in progress
作業中
0608デフォルトの名無しさん2011/04/20(水) 23:46:00.99
>>600
え？cloneは？
0609デフォルトの名無しさん2011/04/21(木) 00:12:36.21
cloneはリポジトリ作成時くらいだからよく使うもんでもないだろう
0610デフォルトの名無しさん2011/04/21(木) 01:09:31.21
>>599
有料なら大丈夫
06116042011/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.* の保守ブランチを作る。

0612デフォルトの名無しさん2011/04/21(木) 07:54:20.34
git svnで、SVNレポジトリをcloneして使ってるんだけど、
SVNだと、ローカル開発環境用に設定ファイルを書き換えておいて放置、みたいな
運用ができるけど、Gitではどうすべきなんだろう。
git svn rebaseすると、updateしてないって怒られちゃうし。
0613デフォルトの名無しさん2011/04/21(木) 08:02:15.70
>>612
master は svn-rebase & svn-dcommit 専用ブランチとして割りきって
俺作業用ブランチの上であれこれするのがよい。

俺の場合、dcommit する際には cherry-pick が基本だな。
git-svn と暮らすには、rebase 基本のワークフローにするのがベターと思う。
0614デフォルトの名無しさん2011/04/21(木) 22:19:31.29
>>609
git clone を cvs checkout と同じ用途で使うバカもいるみたいだぞ。
これが一番確実、とか意味不明なこと言って。
0615デフォルトの名無しさん2011/04/21(木) 22:50:36.78
えﾞ、俺バカだ。
じゃあ作業コピー作りたいときはどうするの？明示的にgit remote add & fetch？
0616デフォルトの名無しさん2011/04/21(木) 23:06:49.83
>>613
gitはリモートのファイルにオレオレパッチやオレオレ修正あてたまま、
公式のリリースに追従していくとが楽でいいよね
これだけでもsvnから移行したかいがあった
svnでもできるかもしれないし、gitというか分散型の特徴なのかもしれないけれど
0617デフォルトの名無しさん2011/04/22(金) 08:02:28.33
>>613
>>616
なるなる。ありがとう。
0618デフォルトの名無しさん2011/04/22(金) 09:48:13.13
地震に備えてソースコードをバックアップして置きたいのですが
GITでオンライン上で非公開でソースコードを置ける無料のサイトってありますか？
0619デフォルトの名無しさん2011/04/22(金) 09:54:23.06
DropBox等につっこむとか
0620デフォルトの名無しさん2011/04/22(金) 12:50:36.57
>>618
mercurialに変換してbitbucket
0621デフォルトの名無しさん2011/04/22(金) 13:33:51.09
>>614
答えは？
0622デフォルトの名無しさん2011/04/22(金) 17:58:49.88
>>611
正当というのがどういうのか分からないけど、
ローカルにタグ、リモートにブランチが欲しいなら、
そういう感じで良いんじゃないですかね。

リモートのHEADをmasterから動かすのは、Gitコマンドだけじゃ出来ないっぽい。
GitHubはWebから出来るようになってるけれど。

>>612
stashを使うというのも手ですね
0623デフォルトの名無しさん2011/04/23(土) 07:56:03.50
>>618
Gist
0624デフォルトの名無しさん2011/04/23(土) 08:45:16.80
>>623
あの"Private"はURLが分かれば誰でもアクセスできるよ
0625デフォルトの名無しさん2011/04/23(土) 12:06:08.47
>>618
assemblaはどう？
0626デフォルトの名無しさん2011/04/23(土) 18:14:18.55
バージョン管理というものはいまいちよく分かりません
まず、Gitを入れました
リポジトリを作成しました（おまじないみたいなものでしょうか？）
書いたソースコードをコミットしました（これはソースをバックアップするって意味であってますか？）
取り出すときに、○番目のソースコードを取得する方法が分かりません
あと、入門サイトとかでは取得するときフォルダを作成しているのですが、書いているファイルに読み込ませられないのでしょうか？
0627デフォルトの名無しさん2011/04/23(土) 18:21:33.84
>>626
そもそも「なぜバージョンを管理する必要があるののか」というのを先に学んだ方が良いかも。
必要に迫られてバージョン管理しようと思った人は「なぜ」が分かるから、一つ一つの作業の
意味を掴みやすい。

漠然と始めたりすると「なぜ」必要なのか分からないから、リポジトリ・コミット・履歴管理と
言った言葉で、バージョン管理ソフトが何をしようとしているのか理解できないのかも。
0628デフォルトの名無しさん2011/04/23(土) 18:24:01.37
>>626
Pro GitかGitのチュートリアル嫁ええぇぇ
ちゃんと最後まで嫁ええぇぇ
Git入門 - ドキュメント
http://www8.atwiki.jp/git_jp/
Pro Git - Table of Contents
http://progit.org/book/ja/

それか濱野神のGit入門嫁えええぇぇ
Amazon.co.jp： 入門Git: 濱野 純(Junio C Hamano): 本
http://www.amazon.co.jp/exec/obidos/ASIN/4798023809/
こっちはコミットとは何か、とかいう基本から書いてあるぜー
0629デフォルトの名無しさん2011/04/23(土) 18:28:10.68
atwikiの法は難しくて挫折しました（ぇ
もうかたほうのサイトで勉強してみたいと思います
６２７さん６２８さんありがとうございます
0630デフォルトの名無しさん2011/04/24(日) 16:23:10.58
git branch test
したあとで
git branch test/foo1
すると怒られて切ないです
なんとかなりませんか
ブランチ名の区切り子に / を使うこと自体がアレなのかもしれませんが
0631デフォルトの名無しさん2011/04/24(日) 17:21:11.86
それはtouch fooしたあとmkdir fooしたら怒られるってくらい理不尽だと思うｗ
/以外の記号じゃダメなん
0632デフォルトの名無しさん2011/04/24(日) 17:29:22.25
/ は git branch のとき内包的関係が見やすいんだよね
　test_vol1/foo
　test_vol1/bar_baz
：： もよくね、と思ったんだがファイルシステムの制限で使えなかったり
仕方ないので
　test_vol1-foo
　test_vol1-bar_baz
というようにしてる
微妙に見にくい
0633デフォルトの名無しさん2011/04/24(日) 18:54:11.87
/区切りのブランチ名を総括できればうれしいんだが…
eg. $ git push github orepatch/*

ところで msysgit にて、 git commit のエディタを TortoiseGit が起動するようにできない?
msysgit 付属の vim は嫌いだ。いつも日本語でcommitするときだけ
TortoiseGit 使ってるが、まどろっこしくてしょうがない。
最近はあまりのメンドくささに、git commit -m"fizzbuzz" とかやって
Linux でコミットメッセージを編集しなおしてる。
0634デフォルトの名無しさん2011/04/24(日) 19:44:54.94
>>624
知らなかった！！
0635デフォルトの名無しさん2011/04/24(日) 22:03:36.39
>>624
mjd?
0636デフォルトの名無しさん2011/04/24(日) 22:55:16.92
>>635
http://support.github.com/discussions/gist/119-private-gist-is-not-secure
0637デフォルトの名無しさん2011/04/24(日) 23:03:57.67
>>632
test_vol1が無ければ、これはできるでしょ
test_vol1/foo
test_vol1/bar_baz
0638デフォルトの名無しさん2011/04/25(月) 03:15:01.66
>>636
Megauploadにプライベートファイル置いた時並にひでぇｗ
↑個人ストレージのつもりで借りたら丸見えだったでござる
0639デフォルトの名無しさん2011/04/25(月) 08:00:29.25
ttp://article.gmane.org/gmane.comp.version-control.git/171996
1.7.5ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
0640デフォルトの名無しさん2011/04/28(木) 16:48:35.50
Gitで、マージ時に同じコミットが2回適用される可能性がある場合、どのような挙動なのか教えてください。

たとえば以下のようなブランチがあったとします。
・master
・dev1
・dev2
・bugfix
ここで、bugfixブランチを、dev1とdev2にマージしたとします。
（bugfixブランチじゃなくても、あるコミットをcherrypickでdev1とdev2に当てた場合でもいいです）
この状態では、コミット番号こそ変わるものの、変更内容が同じコミットがdev1とdev2に適用されています。
このような状態でdev1とdev2をmasterにマージしたとき、どのような挙動になるのでしょうか。
やっぱりconflictが発生してしまうのか、それともGitがすごく賢くて重複するようなコミットのうち1つだけを適用するのか。
詳しい方おしえてください。
0641デフォルトの名無しさん2011/04/28(木) 17:18:16.56
>>640
とりあえずやってみようぜ？
rebaseが自動判定してくれるのは知ってるけど、mergeはどうだったっけなぁ。
0642デフォルトの名無しさん2011/04/28(木) 17:48:46.24
>>641
Gitはまだ触ったことないんでちょっと試すというわけにはいかないんですが、
マージがどのくらい賢いのかがわかんなくて、すごく賢いようだったら
Gitの勉強をしようかなと思って、その判断をするために質問しました。
>>640が分かる方いましたらよろしくお願いします。
0643デフォルトの名無しさん2011/04/28(木) 18:20:52.96
>>642
ちょっと触るぐらい簡単だろうよ…cherrypickとか知ってるんなら他のVCS使ってるんだろ。
何にもしないでただ教えろって知恵袋かよ。

マジレスするとmergeは3wayマージするだけなので間のコミットとか関係ない。
マージベースがちゃんと取れれば、同じコミットが含まれてたりする場合でも
たいていうまくいく。あまり行が近かったりすると別の意味でconflictになるけど。
0644デフォルトの名無しさん2011/04/28(木) 23:08:57.87
dropboxって30日で消えるんですか？
コードのバックアップに適しているところって他にありますかね
半年ぐらいネットから離れる場合はどこのオンラインストレージがいいでしょうか？
無料でお願いします
0645デフォルトの名無しさん2011/04/28(木) 23:15:58.51
dropbox内のフォルダをgitやらなんやらでバージョン管理すればいいよ
0646デフォルトの名無しさん2011/04/28(木) 23:23:11.21
ああ，専ブラで横のタブにDropbox総合スレがあったから見間違えた
Dropboxは古いバージョンのファイルが30日で消えるだけで，全部のファイルはずっと残ったままだぞ
バージョン情報を保ちたいなら，リポジトリ自体をDropbox上に作れという話
0647デフォルトの名無しさん2011/04/28(木) 23:31:45.63
ということは常に最新のファイルは消されないってことですね
でも半年後にサービスが終了したら怖いな
0648デフォルトの名無しさん2011/04/28(木) 23:56:58.01
>>647
一時期、cronで定期的にzipして自分のgmail口座にメールで送るというのを
バックアップとして使ってた。　
0649デフォルトの名無しさん2011/04/29(金) 00:05:19.85
Git+GAEで管理できたらいいな
0650デフォルトの名無しさん2011/04/29(金) 09:29:23.51
>>647
そんな心配していたら、何も使えないだろ。
ローカルのHDDが吹っ飛ぶ可能性だってあるんだぜ。
0651デフォルトの名無しさん2011/04/29(金) 10:46:27.58
テスト中 utf8-git-on-windows
http://code.google.com/p/utf8-git-on-windows/
0652Perl忍者2011/04/29(金) 23:45:00.87
githubとsvnの違いを説明してください
わかりません
イマイチよくわかりません
メリットデメリットなど
0653デフォルトの名無しさん2011/04/29(金) 23:45:53.95
githubがphpでsvnがperlだ
0654Perl忍者2011/04/29(金) 23:46:53.02
svnっていうやつはサーバー立てるんですか？
githubっていうのはWEBから操作できるやつですか？

バージョン管理システムについておしえてください
0655Perl忍者2011/04/29(金) 23:47:15.60
>>653
まじめにこたえろはげ
0656Perl忍者lvl4 ◆M5ZWRnXOj6 2011/04/29(金) 23:48:18.84
偽きめえなw
まぁこの偽かわいそうだから
教えてやればw
0657Perl忍者2011/04/29(金) 23:48:43.27
はい　教えてください
0658Perl忍者2011/04/29(金) 23:52:18.38
教えろよボケ
0659Perl忍者2011/04/30(土) 01:20:47.51
はよ教えろｗ
0660デフォルトの名無しさん2011/04/30(土) 09:54:17.96
>>659
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/
0661デフォルトの名無しさん2011/04/30(土) 16:43:17.27
>>633
core.editorに好きなテキストエディタを設定すればよろし
コミットログに使っている文字コードを指定するのを忘れないようにしてね
テキストエディタの代わりにシェルスクリプトやバッチファイル経由で立ち上げてもいい

適当にググッてきた参考サイト
gitで秀丸を使う方法 - hClippr編集室ブログ
http://d.hatena.ne.jp/unsignedint/20090303/1236138302
0662デフォルトの名無しさん2011/04/30(土) 22:02:15.20
宣伝成功！！ｗｗｗ
0663デフォルトの名無しさん2011/05/01(日) 15:28:09.15
dropboxでコードのバックアップ取っている方に質問です
dropboxで提供しているクライアントはインストールして使ってますか？
0664デフォルトの名無しさん2011/05/01(日) 15:54:20.62
むしろ、使わないでどうするんだｗ
手動でUpDownに同期までするならdropboxを使う理由もない。
0665デフォルトの名無しさん2011/05/01(日) 16:48:55.30
C:\Users\ユーザー名\Dropboxが出来たけどいまいちよくわかんないし
このフォルダだけしか同期されないようになってるんだよね？
保存して右クリックで同期するとか、ファイルを保存したら勝手に同期そういうのだと思ってた
毎回dropboxのフォルダに保存したいファイルをコピーするのめんどくせえ
0666デフォルトの名無しさん2011/05/01(日) 17:03:23.57
Gitスレでやることじゃねえだろ
どっかいけ
0667デフォルトの名無しさん2011/05/01(日) 17:06:02.81
>>665
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/
0668デフォルトの名無しさん2011/05/01(日) 17:24:35.63
なんでdoropboxスレで聞かないの？
0669デフォルトの名無しさん2011/05/01(日) 20:29:37.81
VS2008にgit extentionsつっこんだんだけど、
VSのプラグインから見るとcygwinからコミットしたログが文字化けする。
エンコードをUTF-8にすると直るけど、こんどはCP932のファイル差分が文字化け。
なんか方法はないもんかね？
0670デフォルトの名無しさん2011/05/01(日) 22:55:27.29
コミットログを書くときのエンコーディングを統一するか、
Textconvにnkfを使ってコミットログを出力するときのエンコーディングを統一すれば良いんでは？
0671デフォルトの名無しさん2011/05/02(月) 08:23:56.45
リモートのブランチを全部再現することってできませんか？
git clone したら master しか持って来れなくて困りました
0672デフォルトの名無しさん2011/05/02(月) 08:34:05.59
git fetch --all
それが貴殿の望みどおりの動作をするとは思えん。
0673デフォルトの名無しさん2011/05/02(月) 08:34:47.08
書いたあとで思ったが
git branch -r
を実行したことがあるのだろうか?
0674デフォルトの名無しさん2011/05/02(月) 09:00:43.41
>>671
git branch は引数を2つ取ることができる(普段は1個)
git branch hoge origin/hoge
とするとリモートにあった hoge が監視下に入る
リモートになにがあったかの情報は git clone した時点で既に手元に来てるので
git branch -a でもして表示しれ

一発ではできない気がするので、適宜使うブランチだけ再現
0675デフォルトの名無しさん2011/05/02(月) 10:25:52.47
>>665
Dropboxは場所が固定だが、
SugarSyncみたいな任意のフォルダを同期できるサービスもあるよ。
0676デフォルトの名無しさん2011/05/02(月) 14:26:16.02
>>646
>バージョン情報を保ちたいなら，リポジトリ自体をDropbox上に作れという話
これやってるけど無茶苦茶便利。
自分の開発機だと別のマシンでもチェックアウトする必要ないんだもん。
0677デフォルトの名無しさん2011/05/02(月) 16:19:31.09
>>676
それって多人数開発でもうまくいくの？
なんだか一人開発が前提のように見えるけど。
0678デフォルトの名無しさん2011/05/02(月) 16:45:30.32
publicで共有すればできるだろ
0679デフォルトの名無しさん2011/05/02(月) 17:09:53.63
>>677
もちろんDropboxは一人だけですよ。
何のための分散型バージョン管理なんですかっ
0680デフォルトの名無しさん2011/05/02(月) 18:31:14.55
dropboxを一人で使うことと分散型に関連性があるのか。
0681デフォルトの名無しさん2011/05/02(月) 18:46:56.77
1つのdropboxを多人数で使うのは集中型的手法。
多数のdropboxを多人数で使うのは分散的手法。
0682デフォルトの名無しさん2011/05/02(月) 20:07:14.88
多数のdropboxを使うと言ったって共有する部分は集中型じゃん。
0683デフォルトの名無しさん2011/05/02(月) 21:51:34.46
集中しなくてもいいんですよ
0684デフォルトの名無しさん2011/05/02(月) 23:04:07.25
なんのスレ
0685デフォルトの名無しさん2011/05/02(月) 23:46:21.89
ここは初めてか? ケツの○を抜けよ.
0686デフォルトの名無しさん2011/05/02(月) 23:48:39.80
バザアッー！
0687デフォルトの名無しさん2011/05/02(月) 23:50:16.66
>>682
「多数」＝多○○数○
なるほど
0688デフォルトの名無しさん2011/05/04(水) 11:06:14.15
dropboxでgitを管理する方法を教えてください
dropboxでインストールしたらC:\dropboxが出来ました
ここにgitのリポジトリを作ればいいんですか？
あと、コミットはどこにやればいいのでしょうか？
dropboxのサイトのほうですか？それともc:\dropbox内のgitのリポジトリに対してですか？
それと、30日でファイルが消えるってありますが、30日以内にファイルをコミットし続けないといけないのでしょうか？
そのへんはマクロとか使えば何とかなりますが・・・
0689デフォルトの名無しさん2011/05/04(水) 11:22:02.21
馬鹿には無理
0690デフォルトの名無しさん2011/05/04(水) 11:25:51.51
しね
0691デフォルトの名無しさん2011/05/04(水) 11:40:33.59
>>688
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/
0692デフォルトの名無しさん2011/05/04(水) 12:43:06.72
何故彼はdropboxでgitを管理しようと思ったのか・・・w
dropboxでgitを管理する上で特有の何かを聞きたいわけでもなさそうだし

>>688
一つずつ学んでいこう
まずはgitの使い方、次にDropboxの使い方を学ぼう
逆でもいい

それから、gitのリポジトリをDropboxで管理する方法が適切かどうか判断したほうがいい
俺ならgitのリポジトリをDropboxには置かないがこれは俺の判断だし
0693デフォルトの名無しさん2011/05/04(水) 12:57:43.83
だってさ無料で非公開で管理できるサーバが欲しかったんですよ
俺は金がないから自分でどりょくしてここまで来たのですよ
0694デフォルトの名無しさん2011/05/04(水) 13:07:51.10
>>693
つ>>620
0695デフォルトの名無しさん2011/05/04(水) 13:23:35.48
>>688
> ここにgitのリポジトリを作ればいいんですか？
まずやってみろよ

> あと、コミットはどこにやればいいのでしょうか？
まずやってみろよ

> dropboxのサイトのほうですか？それともc:\dropbox内のgitのリポジトリに対してですか？
まずやってみろよ

> それと、30日でファイルが消えるってありますが、30日以内にファイルをコミットし続けないといけないのでしょうか？
Dropboxスレで聞けよ
0696デフォルトの名無しさん2011/05/04(水) 13:34:16.16
やりたいんですけど壊れたら怖いので聞いてみたのですよ
お年玉も使っちゃったし自分でパソコン変えないしまだ小５だから
0697デフォルトの名無しさん2011/05/04(水) 13:48:56.17
しね
0698デフォルトの名無しさん2011/05/04(水) 13:56:43.47
おじさん、しねって言葉は使っちゃダメですよ
0699デフォルトの名無しさん2011/05/04(水) 14:44:44.39
バージョン管理システム動かしたくらいでPCが壊れるわけねーだろ
Gitどうこう以前に頭が弱すぎて話にならん
0700デフォルトの名無しさん2011/05/04(水) 16:47:29.75
低脳に居座られてこのスレも大変だなｗ
0701デフォルトの名無しさん2011/05/04(水) 17:02:13.91
おまえもな
0702デフォルトの名無しさん2011/05/04(水) 19:47:40.06
一昔前の週刊アスキーに
「Firefoxの新バージョンのインストールは最悪OSの入れなおしも覚悟しといて」
とかさらりとすごいこと書いてあったな(板違いｽﾏｿ)
0703デフォルトの名無しさん2011/05/04(水) 20:37:44.38
はあ？
0704デフォルトの名無しさん2011/05/04(水) 20:43:39.09
>>703
うん、にわかには信じられないだろ？
でも書いてあったんだよマジで…
0705デフォルトの名無しさん2011/05/04(水) 21:55:12.92
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/
0706デフォルトの名無しさん2011/05/04(水) 23:07:31.48
WinだけどFirefoxってブラウザのくせにインストールするとちゃっかりサービスに登録しちゃうんだよな
0707デフォルトの名無しさん2011/05/04(水) 23:57:44.50
えっ
0708デフォルトの名無しさん2011/05/05(木) 00:01:22.59
えっ
0709デフォルトの名無しさん2011/05/05(木) 00:03:15.61
えっ
0710デフォルトの名無しさん2011/05/05(木) 00:10:14.05
知らないなら自分で確認したらどうだ
0711デフォルトの名無しさん2011/05/05(木) 06:17:18.02
えっ
0712デフォルトの名無しさん2011/05/05(木) 07:10:57.26
えっ
0713デフォルトの名無しさん2011/05/05(木) 07:11:22.23
最近このスレも活発になってきましたね！！
0714デフォルトの名無しさん2011/05/05(木) 07:21:39.30
かなりどうでもいいけどPerl忍者ってさ
http://blog.plaync.jp/giko/302948.slog
0715デフォルトの名無しさん2011/05/05(木) 08:43:29.54
えっ
0716デフォルトの名無しさん2011/05/05(木) 11:57:28.48
馬鹿の一つ覚え
0717デフォルトの名無しさん2011/05/05(木) 12:53:38.58
えっ
0718デフォルトの名無しさん2011/05/05(木) 15:15:48.56
えっ
0719デフォルトの名無しさん2011/05/05(木) 15:40:09.17
https://github.com/treeboa
0720デフォルトの名無しさん2011/05/05(木) 21:47:51.99
うわ、糞の役にも立たない手抜きソフトしかない(棒
0721デフォルトの名無しさん2011/05/06(金) 00:01:34.59
>>705
ダム板はいいとして実質マスコットはoctocatだからな・・・
0722デフォルトの名無しさん2011/05/06(金) 00:24:02.96
だから おくときヤト なんでしょ
おもしろくないけど
0723デフォルトの名無しさん2011/05/06(金) 01:54:46.92
マスコットはどーもくんだろ
0724デフォルトの名無しさん2011/05/06(金) 10:11:43.71
>>722
やっとわかったwww
0725デフォルトの名無しさん2011/05/08(日) 18:51:02.84
makeするといくつかの実行ファイルができます。
UNIX環境なので、exeのような拡張子がありません。
バイナリファイルを追跡から除外する良い方法はありませんか。
0726デフォルトの名無しさん2011/05/08(日) 18:58:12.22
>>725
出力されるパスは決まってないの？
0727デフォルトの名無しさん2011/05/08(日) 19:16:04.67
>>726
ファイル名を決め打ちできないこともないのですが、
開発しているうちにいろいろ変わるのです。
たとえば、main_foo, main_bar, main_baz, ... のように。
一方、main.c, main.h, ....などがいろいろあるので、
.gitignore に
main*
!*.c
!*.h
...
のように書けばいいのかな。
0728デフォルトの名無しさん2011/05/08(日) 19:45:28.75
これまた随分と保守しづらい開発方法取ってんだねえ・・・ｗ
0729デフォルトの名無しさん2011/05/08(日) 20:28:05.33
出力フォルダを別にするとかかなあ
0730デフォルトの名無しさん2011/05/09(月) 01:09:01.19
>>728
>>729

なし崩し的に開発してきたので、自分でも少し整理が必要だと思いました。
07316792011/05/09(月) 15:56:41.95
>>680
ネタがちょいと古いけど・・・
Dropboxを多人数で開発するときの共有レポジトリの管理場所にするって話だと
二人で同時に触っていると問題がでる。
だから、Dropboxを複数人で触る場所には出来ない。
多人数で開発する場合は、やはりサーバを立ててそこにpushする開発スタイルに
ならざるを得ないと思っている。
だから、個人の作業を複数マシン(家と会社とモバイルとか)にまたがって
持ち越せたら便利だな、という所で、その持ち越しをDropboxを使ってやったという話なのです。
もちろん、そのスタイルはSubversionのワーキングコピーに対してでも可能だし
VCSの種類にあまり依存しないと思う。

ただ、>>677 がDropboxを多人数開発の手段として使うという誤解をしているようだったので
それに対して異を唱えておきたかった、というのが>>679

Dropboxを使えば、一人で開発を始めるときに使い始めて
後でサーバを立てたときもその流れで環境を使い続けられると言うのがいい事かと。
0732デフォルトの名無しさん2011/05/09(月) 17:03:17.89
そういう用途ならこれ便利かもね
ttp://uu59.blog103.fc2.com/blog-entry-9.html
0733デフォルトの名無しさん2011/05/10(火) 00:26:48.98
>>731-732
リポジトリだけをDropboxにおくってこと？
これってリポジトリ壊れないのか。
検索したら、壊れるからとTrueCryptに入れてDropboxに入れている人がいた。
ようするに1つのディスクイメージに入れるってことだと思う。Dropboxは1ファイルでも差分同期してくれるから早いらしい。
0734デフォルトの名無しさん2011/05/10(火) 04:21:52.82
そりゃリポジトリとDropboxの更新が非同期なんだから、中途半端にsyncしたあと
接続が切れたりしたら別マシンから見たとき壊れててもおかしくない
TrueCrypt使えば壊れないってのは理屈がわからないな
0735デフォルトの名無しさん2011/05/10(火) 04:46:08.36
Dropboxよくわからないけど、手動で完全にSyncできるなら壊れにくくはなるのかな。

リポジトリをまるごとリモートマウントしたら、本末転倒な気もするけどねぇ。
0736デフォルトの名無しさん2011/05/11(水) 14:19:31.63
git svnで作ったリポジトリでblameしたら

00000000 (Not Committed Yet 2011-05-11 14:15:58 +0900 1)

のように、コミットハッシュと日時の部分がどの行でも同じになってしまうのはどうしてでしょう？
git cloneで普通に作ったリポジトリではこうはなりません。
svnからでなく、gitからコミットした行の部分は、表示されていることもあるようですが
0737デフォルトの名無しさん2011/05/11(水) 23:38:56.61
>>736
それってまだコミットされてない行だよ。
git svnがうまくいってないんじゃない？
07387362011/05/12(木) 22:48:00.13
>>737
作業コピーのファイルは弄っていないです

blameを始めるコミットハッシュを指定すると正常に表示されました
でも、いちいち指定しないといけないのは面倒です・・・
git svnがうまく行っていないとはどういう事でしょうか？
他のgit svnで作ったリポジトリでblameをしてみても、同じような事が起こります
そのリポジトリをgit cloneして、もう1つリポジトリを作っても同じでした

git blame COMMIT_HASH.. -- filename
0739デフォルトの名無しさん2011/05/13(金) 00:32:11.02
COMMIT_HASHにHEADって指定したらどうなる？
07407362011/05/13(金) 21:51:58.64
>>739
同じです・・・
Not Commited Yetの行ばかりになります
0741デフォルトの名無しさん2011/05/13(金) 22:54:10.75
>>740
ちゃんとクリーンな状態なの？ git statusしてmodifiedとか出てない？
0742デフォルトの名無しさん2011/05/14(土) 13:33:11.55
〇〇というブランチの××というファイルの内容を参照して書きたい、という場合に、うまい表示法はありませんか
ターミナルに表示されるだけでいいのですが
0743デフォルトの名無しさん2011/05/14(土) 14:06:27.71
>>742
そんなあなたにgitg
いつもおそばにgitg
※ gitkでも可

ブランチ選んでコミット選んでtreeタブをクリックしてディレクトリたどってファイルをクリックするとあら不思議
0744デフォルトの名無しさん2011/05/14(土) 14:17:16.05
>>743
うおー
なにこのものぐさソフト
0745デフォルトの名無しさん2011/05/15(日) 14:01:13.40
>>742
git show branch:path
0746デフォルトの名無しさん2011/05/15(日) 14:05:53.52
git checkout .
でコミット後のファイルの変更が全部なかったことになってコミット直後に戻るのはなんで？
っていうかオペミスが怖いんだけど
0747デフォルトの名無しさん2011/05/15(日) 14:48:19.99
git rebase した
コンフリクトした
訂正して git add した
git rebase --continue した

……？

ttp://www.google.com/search?q=%22No+changes+-+did+you+forget+to+use+%27git+add%27%3F%22&ie=utf-8&oe=utf-8

引っかかってる人は多い模様
0748デフォルトの名無しさん2011/05/15(日) 15:15:04.33
バージョンいくつの話？
うちは1.7.5だけど全く同じことを昨日やって問題なかったが
0749デフォルトの名無しさん2011/05/15(日) 16:09:42.54
うーんと、Ubuntu10.10 だから git 1.7.1 で、…うん、1年前のだな
0750デフォルトの名無しさん2011/05/15(日) 19:51:19.21
>>746
カレントディレクトリ「.」にHEADのファイルを再帰的にチェックアウトしろ
ってことだから、当然そうなるもんだと思ってたけど・・・
0751デフォルトの名無しさん2011/05/15(日) 21:22:52.33
てかcheckoutってそういうもんじゃないんだっけ
0752デフォルトの名無しさん2011/05/15(日) 21:37:13.53
--force があっても良いかもと思わなくもない
0753デフォルトの名無しさん2011/05/15(日) 22:00:00.04
>>746
git checkout ''
でも同じようになるね
0754デフォルトの名無しさん2011/05/16(月) 00:17:15.24
質問です。

TortoiseGITと使いはじめたばかり初心者です。

先ほどリモートからpullしてきたばかりのソースなのですが、ファイルや
フォルダにところどころ「！」マークの赤いアイコンがついているものがあります。

これはどのような事を意味しているのでしょうか？

サブバージョンで「！」は変更したファイルなどにマークされていた思いますので、
poullしてきた瞬間になんらかの変更がなされてしまったということなのでしょうか？
0755デフォルトの名無しさん2011/05/16(月) 03:54:03.30
autocrlfあたりが発動して改行コード変わってるんじゃね
0756デフォルトの名無しさん2011/05/16(月) 06:03:17.93
そもそも git-chekcout はブランチ名とファイルパスの引数2つなのよ
珍しく、機能を分割できなかった例だと思う
引数が省略されることで「全く別」の動作をしてしまう

カレントブランチの変更はコマンドとして独立させて別名を与えるべきだった
〇〇のチェックアウトが「〇〇ブランチへの移動」だなんて冷静に考えてやっぱり変だろう
0757デフォルトの名無しさん2011/05/16(月) 07:03:23.79

GitHub will switch to English-only on Friday, May 20, 2011.
ttps://gist.github.com/a4b4fac18beb08335919
0758デフォルトの名無しさん2011/05/16(月) 07:42:37.85
>>756
1リポジトリに1作業ツリーというのがGitの特徴でもあるからね。
他のVCSみたいにブランチ毎に別ディレクトリにチェックアウトしたりしないから
まずそこで戸惑ってるんでしょ。そこが理解できればgit-checkoutのやり方でも
違和感無いはず。

そもPlumbingのコマンドを複数組み合わせて手間を無くしたのがPorcelainだから、
複数の動作が組み込まれちゃってるのも道理。
0759デフォルトの名無しさん2011/05/16(月) 13:10:06.57
git cherry-pick はコミットを「持ってきて」現在のブランチにコミットするが、
git cherry-pick --no-comit は、選ぶだけでコミットを行わないらしい

素晴らしい！
ハッピーバースデイ！

git cherry-pick -n 111a
git cherry-pick -n 111b
git commit -m "111でした"
git log

- 111でした
- master

git cherry-pick -n 222a
git cherry-pick -n 222c
git log

- 222c なんだけどどうしようかな
- master

あれ？ 「111でした」のコミットどこ？
…いや、111a と 111b 自体は適用されてるんだが、コミットメッセージが222cに置き換わってる？
0760デフォルトの名無しさん2011/05/17(火) 03:23:34.66
git://github.com/user/project.git
で
タグv0.1とタグv0.2のdiffを入手したいのでコマンド教えてください。
git-diffを使うのだろうということしかわかりません。

v0.1やv0.2をDLしてdiffするというのは無しでお願いします。
要はgitが提供する一番ネットワークに負荷がかからない方法でお願いします。
0761 忍法帖【Lv=38,xxxPT】 2011/05/17(火) 06:42:28.05
Introducing GitHub Compare View - GitHub
https://github.com/blog/612-introducing-github-compare-view
0762デフォルトの名無しさん2011/05/17(火) 06:52:56.28
>>761
コマンドでは出来ないってことですか？
compareはrawでは無いですよね？

タブ・空白とかがきちんとコピーできるか心配です。
沢山コピペしなければいけないのは面倒です。

http://www.wikivs.com/wiki/GitHub_vs_Gitorious
によれば、raw diffは手に入らないようです。
0763デフォルトの名無しさん2011/05/17(火) 06:57:43.93
>>760
>要はgitが提供する一番ネットワークに負荷がかからない方法でお願いします。
github鯖自体への負荷は問題にしないってか?
0764デフォルトの名無しさん2011/05/17(火) 07:00:31.05
>>763
なぜ別の話になるのですか？
0765デフォルトの名無しさん2011/05/17(火) 07:00:35.51
>>762
>コマンドでは出来ないってことですか？

Git においてリモートリポジトリを操作するという思想はそもそも存在しない。
github.com の compare でどうにもならないのだったらあきらめて fetch しろ。
0766デフォルトの名無しさん2011/05/17(火) 07:10:19.51
>>765
なるほど、「出来ない」のですね。
色々と割り切った考え方の元に作られたツールだと
思ってましたが、そういうのも出来ないのは驚きでした。
使っていたソフトの開発元が svn+trac からgithubに
変わってしまってかなり機能後退と分かりゲンナリです。

普通にDLしてdiffするのが短時間で済みそうなので
これにて。ありがとうございました。
0767デフォルトの名無しさん2011/05/17(火) 07:29:56.81
「分散」型バージョン管理システムなのにリモートリポジトリを操作するって発想がよくわからん
0768デフォルトの名無しさん2011/05/17(火) 07:40:58.12
そろそろ爆釣宣言が来るか?
0769デフォルトの名無しさん2011/05/17(火) 07:44:13.39
github diffでググったら4件目くらいに出てきたよ
0770デフォルトの名無しさん2011/05/17(火) 08:08:43.25
クローラ対策のために 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喰らっちゃったよ。
0771 忍法帖【Lv=38,xxxPT】 2011/05/17(火) 08:56:07.88
>>770
.patchのほうが生のパッチだよね
.diffのほうはそのままだとpatchには食わせられなかったりする
0772デフォルトの名無しさん2011/05/17(火) 16:57:16.85
git checkoutって変更したファイルは確認でなかっけ？
0773デフォルトの名無しさん2011/05/17(火) 17:14:08.84
わっ確認出ないなあぶねー
0774デフォルトの名無しさん2011/05/17(火) 17:14:59.82
コミット前でreflogにもでないし開発中にやったら悶絶するなこれ
0775デフォルトの名無しさん2011/05/17(火) 17:47:40.52
パス指定したらそりゃ上書きするでしょう…そういうものだもの
0776デフォルトの名無しさん2011/05/17(火) 17:50:27.16
だから git-checkout branch_name は「ブランチ移動コマンド」ではないと何度
0777デフォルトの名無しさん2011/05/17(火) 23:34:48.83
>>760
git clone git://github.com/user/project.git
cd project
git diff v0.1 v0.2
0778デフォルトの名無しさん2011/05/17(火) 23:39:46.40
mjrs ktkr
0779デフォルトの名無しさん2011/05/17(火) 23:42:20.84
　　　　　　　　　i　　　　　 　 　 　 　 　 　 ｉ ｌ l
.　　　　　　　 　 !　　　　　　　　　　　　 　 ｉ | |
　　　 　 　 　 　 !　　 　 　 　 　 　 　 　 r¬| ｈ
　　　 　 　 　 　 i　　　　　 　 　 　 　 　 ｀TY´ !
　　　　　　 　 　 i 　 　 　 　 　 　 　 　 　 { 　丿
　　　　　　　　　 i　　　　　　　　　　　　　 ｊ　/|
　　 　 　 　 　 　 !　 　 　 _ ＿ _ 　 　 　 /　ｌ!｣
　　　　　　　　 　 !　　／.::.::.::.::.::.｀ヽ、　ハ ﾉ
　　　　　　　　　　i　/.::.::.::.::.::.::.::.::.::i:.:〉/ 　 〉
　 　 　 　 　 　 　 i ｉ.::.;:.::.::.::.::.::.:::i::.:ﾄ'/　　/
　　　　　　　 　 　 !|:.::ｉ.::.::.::.::.::.::lﾘ:::ｊ/ 　 /　　　釣れたー!!
　　　　　　　　　　 !l::::l:::.:::.:::.:::;:;ﾙイ　　/
　　　　　　　　　　 |'V:ﾄＮlVﾙ'´ﾉ　丶 /
　　　　　　　　　　 L乂^〈､__／　　　〈
　　　　　　　 　 　 {いゝ、　　 　 　 '　ヽ
　　　　　　　 　 　 ﾄ｢`ヽﾊ. 　 ヽ 　 !　丿
　　　　　　　　　　 ﾄ! : : Vﾍ　　　　广´
　　 　 　 　 　 　 ,ﾊｌ : : 人∧、　 /
.　　　　　　 　 ／　ﾊ／ 　 (尢)、{
　　　　　　　　入_,ﾙ' -─−:八ヽl、
　　　　r─‐'´ ／ {.: : : : : : : : ;ﾊ、 〉
　　 　 ´￣`ゾ　　ヽ､: : : : :／　 l｀|
　　　　　　　　　　！ ｀ ｰｲ　 　 ヽl
　　　 　 　 　 　 　 `、　 │　　　 |
　 　 　 　 　 　 　 　 ヽ＿｣､＿＿｣
　　　　　　　　　　　　 ヽ::::ｌ:::::::::::::|
0780デフォルトの名無しさん2011/05/18(水) 10:51:59.13
>>777
> 要はgitが提供する一番ネットワークに負荷がかからない方法で

と思ったが条件はみたいしてるか
0781デフォルトの名無しさん2011/05/18(水) 12:12:20.78
都度 clone するヤツは頃してもいいとオモ
0782デフォルトの名無しさん2011/05/19(木) 23:20:09.07
TortoiseGitってDebugだと全然ビルド通らない
DebugだとReleaseと全然プロジェクトの設定が違っていたりする
気づかずに放置するということは、ろくにデバッグをしていないということか
0783デフォルトの名無しさん2011/05/20(金) 00:14:43.88
リリース用じゃないんだろ
0784 忍法帖【Lv=9,xxxP】 2011/05/20(金) 02:46:09.63
Gitは、スゲーむずかしいから、分散VCS初心者は
もっとわかりやすいのをやったほうがいい。

gitは結局、パッチ(実体はblob)がリンクリストで並んでいるのを
イメージして、ローカルのリポジトリと、リモートのリポジトリ
の操作をイメージせにゃならん。

トラブったときも、パッチ(実体はblob)の識別子としてのhash値
で操作とか、こう、プログラムの気持になって操作しないとダメ
だし、自由度が高いが学習コストも高い。

普通のSIerとかだと、むりだわ。
0785デフォルトの名無しさん2011/05/20(金) 08:42:57.02
SIerって。。。
0786デフォルトの名無しさん2011/05/20(金) 08:44:24.94
gitの難しさは既存のバージョン管理と管理方法がかなり離れていることが大きい
ステーシングの扱いとか、したいことに対してコマンド名があっていないとかも混乱の元
ただこれらは、Bazaar Explorerのようなバカチョンツールである程度解決できる

(あくまで簡易的な)ステーシングなんて、GUIだと視覚的にコミットしたいファイルをチェックボックスでポチるだけじゃん
TortoiseSVNですらやってるし、実際は上手く視覚的に伝えられればgitのステージングが分かりにくいなんてことはない

それとgitに限らないができることが多すぎるのでgit flowのような決まったワークフローを強制するツールがあると
使う方は楽なんだよね
0787デフォルトの名無しさん2011/05/20(金) 08:46:51.46
最近オブジェクトレベル(いわゆる低レ)操作スクリプトに凝っている俺が来ますたよ。
0788デフォルトの名無しさん2011/05/20(金) 09:15:49.57
Linusの個人ツールに使いやすさ、分かりやすさを求めるのが間違いです
0789デフォルトの名無しさん2011/05/20(金) 09:41:44.30
プログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
プログラム作ったことのない人にはまあ無理だ
見たことも聞いたこともないものを取り扱うソフトなんて使いこなせるはずがない

今後使いやすくなるとしても、プログラマ的使い勝手の良さが優先されることだろう
…まあ、別に苦行者じゃないので、gitg みたいなのは誰でも歓迎ではあるだろうけど
0790デフォルトの名無しさん2011/05/20(金) 09:41:58.76
>>788
もうLinusは開発に関わってないんだがｗｗ
0791デフォルトの名無しさん2011/05/20(金) 09:56:10.51
メンテナはしてないけどパッチはたまに送ってるよ
0792デフォルトの名無しさん2011/05/20(金) 12:29:25.68
>>789
x プログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
o Unixプログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
07934142011/05/20(金) 13:39:30.82
>>790
http://bit.ly/m4BEAV
07947902011/05/20(金) 14:00:55.30
>>793
指摘感謝
ともあれ今やこの程度のコミット頻度であっても
「プログラマ以外には全くもってわかりにくいように」
というLinusの意思が連綿と生き続けているのは凄いねｗ

>>789
GUIなら分かりやすいんだ、へーｗ
0795デフォルトの名無しさん2011/05/20(金) 15:17:45.62
正直、Gitが分かりにくいということが理解できない。
そんなに不親切かな？　かなりの人が普通にGitHub使ってると思うんだが。
0796デフォルトの名無しさん2011/05/20(金) 15:21:52.27
ユースケースをかいてこの場合はこの手順ってのを一まとめにしてあげたほうがいいんじゃないかな？
いまのところこういうのがまとまってるところ無いしね。

おれみたいなヤツの為にまとめてくれｗ
0797デフォルトの名無しさん2011/05/20(金) 17:18:04.03
>>796
Git での分散作業
http://progit.org/book/ja/ch5-0.html
0798デフォルトの名無しさん2011/05/20(金) 18:25:46.40
Gitを解説したブログとかチートシートがよく話題になってるけど、
あんなんを拾い読みするより、入門Gitを頭からとうして読んだほうが全然いい。
ソースは俺。
0799デフォルトの名無しさん2011/05/20(金) 19:40:37.33
入門Gitを読んだあとはどんな文献を読むと良いでしょうか
gitの基本操作やブランチの操作はばっちりですがいまいちrebaseの辺りが不安です
svnとの連携についても，gitから入ったので既存のバージョン管理ソフトの仕組みが微妙です
0800 忍法帖【Lv=9,xxxP】 2011/05/20(金) 19:48:44.63
>795

Gitで、数人規模から、数十人、よりおおくの、プロジェクトの Merge Master に
なって、そいつらの要求を叶えるために Git を使わないといけないようになったら
ちょっと気分がわかってくれるとおもう。

リポジトリの設計とか、パスワードをプログラムに埋めて後からリポジトリ
のスキャンと再コミットをしたもの(禁断の filter-branch )を、どうやって
適用したらいいかとか途方にくれないか?

他人の痛みを最小限度にして適用する方法を考えないとプロジェクト燃え上がる
かもしれないんだぜ。

これって、もう Best Practice あるの?
0801デフォルトの名無しさん2011/05/20(金) 20:21:38.12
その、どんなVCSを使おうが炎上しそうな条件設定で、何が語りたいの？
0802デフォルトの名無しさん2011/05/20(金) 20:26:42.18
>>800
http://progit.org/book/ja/ch5-1.html

独裁者と若頭型のワークフロー

これは、複数リポジトリ型のワークフローのひとつです。
何百人もの開発者が参加するような巨大なプロジェクトで採用されています。
有名どころでは Linux カーネルがこの方式です。
統合マネージャーを何人も用意し、それぞれにリポジトリの特定の部分を担当させます。
彼らは若頭 (lieutenant) と呼ばれます。
そしてすべての若頭をまとめる統合マネージャーが「慈悲深い独裁者 (benevalent dictator)」です。
独裁者のリポジトリが基準リポジトリとなり、すべてのメンバーはこれをプルします。
0803デフォルトの名無しさん2011/05/20(金) 23:24:23.32
>>800
大丈夫だ
Git以外でも炎上する
0804デフォルトの名無しさん2011/05/21(土) 03:20:19.16
commitするときのコメントを日本語にすると何か不都合あるかな？
0805デフォルトの名無しさん2011/05/21(土) 03:35:50.09
大丈夫だ、問題ない
0806デフォルトの名無しさん2011/05/21(土) 10:13:24.83
一番いい文字コードを頼む
0807デフォルトの名無しさん2011/05/21(土) 11:26:34.61
>>806
TRONコード
0808デフォルトの名無しさん2011/05/21(土) 12:08:30.17
>>798
チートシートっていわゆる日本語で言うとカンペだからね。
理解している人がチラ見するものだよねぇ。
0809デフォルトの名無しさん2011/05/21(土) 15:41:35.38
>>808
良いこと言うね。たしかにその通りだ。
いいから早く使わせろ、って態度でやるから「Gitムズカシイ！！！」とか言い出すんだと思う。
自分のソースコードを任せるんだから、あやふやな理解で良いはずがない。
0810デフォルトの名無しさん2011/05/21(土) 21:47:04.60
## トピックブランチを作成して作業
git checkout -b dev-xxx
git commit -m "..."
git commit -m "..."
git commit -m "..."
## マスターブランチに戻ってマージ
git checkout -b master
git merge --no-ff dev-xxx

というのをよくやるんですけど、この最後の2行をもっと簡単にする方法はありますか。
dev-xxxブランチにいるときに、masterブランチに移動しないままでdev-xxxブランチをmasterにmergeできたらありがたいのですが。
0811デフォルトの名無しさん2011/05/22(日) 00:07:54.68
>>809
ローカルで細々とやってる分には
チートシート程度で理解できないツールは不便だがな
svn, cvs みたくサーバー準備が必要なわけでもなし
分散管理なら「はよ使わせろ」と普通に思うわ
0812デフォルトの名無しさん2011/05/22(日) 00:35:10.43
>>811
集中型の思考回路のままで使うのじゃなければ、チートシートでもいけるんじゃないか。
例えばhgに慣れてる人なら。

>>810
mergeコマンドはカレントのブランチにマージするものだから、出来ないね。
てかマージはコンフリクトする可能性があるから、まずチェックアウトしないとその後が困る。
あと
＞git checkout -b master
の -b は要らないと思う。
0813デフォルトの名無しさん2011/05/22(日) 06:32:29.65
低レベル操作によって、ワーキングディレクトリを一切無視して
- index のバックアップ
- master をindexに読んでくる
- マージ試行
- master をすすめる
- index を戻す
ことはできる。もちろん conflict ナシが前提。

俺も、任意のインデクスに対してマージしてくれるコマンドが欲しい。
0814デフォルトの名無しさん2011/05/22(日) 08:53:46.35
>>812
それ「分かってるヤツがチートシートを読めば分かる」と言ってるだろw
0815デフォルトの名無しさん2011/05/22(日) 13:03:37.20
>>812
>mergeコマンドはカレントのブランチにマージするものだから、出来ないね。
まあそうですね。
ありがとうございました。
0816デフォルトの名無しさん2011/05/22(日) 13:07:27.32
>>814
例えばGit初めてでもhgに慣れ親しんでる人とCVS一本槍の人じゃ、チートシートの効果が全然違うでしょ
0817デフォルトの名無しさん2011/05/22(日) 13:15:08.94
hg glog (graph log) に相当するのは、gitでは何でしたっけ？gitkとかはなしで。
0818デフォルトの名無しさん2011/05/22(日) 13:26:07.45
>>756
>カレントブランチの変更はコマンドとして独立させて別名を与えるべきだった
>〇〇のチェックアウトが「〇〇ブランチへの移動」だなんて冷静に考えてやっぱり変だろう

同意。git swtich ブランチ名 にしてほしかった。
0819デフォルトの名無しさん2011/05/22(日) 13:40:18.45
>>817
hg glogがどういうものかわからんけどgit log --graph --decorateでどう？
0820デフォルトの名無しさん2011/05/22(日) 14:19:05.40
俺は[alias]にsw = checkout というむちゃなエイリアスしてる。
0821デフォルトの名無しさん2011/05/22(日) 14:23:04.93
>>819
あーこれだこれ。ありがとうございます。

別の質問ですが、現在のブランチがどのブランチから分岐したものか調べる方法はありますか。

$ git checkout master
$ git checkout -b dev1
$ git commit
$ git commit
$ git checkout -b fix1
$ git commit
$ git branch | grep '^*'
* fix1
$ ## fix1 の分岐元がdev1であることを調べるには？
0822デフォルトの名無しさん2011/05/22(日) 14:26:35.49
>>813
ちょっとやってみたよ。環境変数で別にインデックスファイルを指定してみた。
http://d.hatena.ne.jp/unpush/20110522/1306041303
コンフリクトした時が問題だけど、低レベルコマンドで出来るね。

ただ、チェックアウトしないでマージするのって、普通はそんなに必要にならないような
気がするんだけど、どういう場面でやるんだろ？
現時点でmasterに戻せるか＆軽く動作確認 とかだとやっぱチェックアウトしないと
と思うんだけどな。
0823デフォルトの名無しさん2011/05/22(日) 16:08:46.16
>>821
それ無いんだよねたぶん。。。ある意味必要かもしれないと思う。
hgにはあったりするのかな？
いちおう、git show-branch でそれっぽい事が分かるよ。
0824デフォルトの名無しさん2011/05/22(日) 17:45:16.50
それっぽいというか、まさにその為のコマンドだけどな。
0825デフォルトの名無しさん2011/05/22(日) 19:09:42.70
hgと同じってこと？
0826デフォルトの名無しさん2011/05/22(日) 22:41:24.23
>>808
上手いこというな
自分でひと通り試した後カンペ(チートシート)を書くと覚えやすいし
後で見ても自分の言葉なので思い出しやすい
自分のためのチートシート書くのは本当にオススメ
0827デフォルトの名無しさん2011/05/22(日) 22:42:50.22
質問です。

まったく履歴の違うふたつのGitリポジトリ間で、
コミットのpushとかpullとかは出来ますか?

〜背景〜
うちの会社では、Subversionを使っているのですが、
別案件に同じコードをベースとして使うことになった場合、
ブランチを切るのではなく、
リポジトリをそのままコピーして使い始める...
というようなやり方をしています。

なので、バグFIXのときなどは、
どちらかのリポジトリで修正を行ったときは、
以下の手順を踏んでいます。
1) 変更点のパッチを作成してあてる
2) コミットログをコピペ

これがいちいち面倒なので、
Gitの機能でうまいことできるのかどうか教えていただけませんか?
別のGitリポジトリから
特定のコミットだけ引っ張ってくる
といったことが出来れば
それを使えるのかとは思うのですが。
0828デフォルトの名無しさん2011/05/22(日) 22:49:04.49
>>827
hgのtransplant拡張なら可能
0829デフォルトの名無しさん2011/05/23(月) 00:41:01.59
>>827
git-svnとcherry-pickでいけるんじゃないかな。

あとGit的には２つのsvnリポジトリが同じになったタイミングでマージして起点を作っといたら
良い感じになりそうなものだけど、svnに戻すことを考えると、そうもいかないんだよなぁ。
0830デフォルトの名無しさん2011/05/23(月) 07:15:41.62
git-cherry は童貞クンを探すコマンドで
git-cherry-pick はおねいさんが童貞クンを妻み喰いするコマンドですよね?
0831デフォルトの名無しさん2011/05/23(月) 07:30:00.89
>>830
0832デフォルトの名無しさん2011/05/23(月) 11:22:23.58
>>821
git branch -vv
0833デフォルトの名無しさん2011/05/23(月) 22:33:08.13
>>810

この前に、pullしなくていいの？

＞## マスターブランチに戻ってマージ
＞git checkout -b master
＞git merge --no-ff dev-xxx
0834デフォルトの名無しさん2011/05/24(火) 02:41:46.09
>>795
あのオプション群が腐ってないと思ってる方が理解できない
0835デフォルトの名無しさん2011/06/01(水) 22:01:57.56
git-svnしたレポに対し、 rXXXXXX みたいなタグを10マンコ生成してみたけどいろいろ糞遅いよ? 死ぬの?
git-pack-refsが焼け石に水みたいな感じ。

このマンコタグをgithubにpushしたら何が起きるかなあ。うひひ。

でも git log --decorate --oneline とか git describe が便利になるんだよな。まんこまんこ。
0836デフォルトの名無しさん2011/06/01(水) 22:55:50.86
>>835
0837デフォルトの名無しさん2011/06/01(水) 23:34:39.51
>>835
0838デフォルトの名無しさん2011/06/01(水) 23:41:35.68
>>835
0839デフォルトの名無しさん2011/06/02(木) 05:55:01.04
あるコミットからあるコミットまでの間に　変更のあったファイル
のリストが欲しいのですが、
Gitではどのようにすれば表示させられますか?
ひとつのコミットについては、
git log --stat
で表示させられたのですが。。。

可能であれば、
　　変更のあったファイル
　　削除されたファイル
　　追加されたファイル
とはっきり分かる形で出力されてくれると助かります。
(--statだと、どれもある意味　変更のあったファイル扱いなので)

すみませんが
もし分かる方がいらっしゃったらよろしくお願いします。
0840デフォルトの名無しさん2011/06/02(木) 06:42:10.18
まずは git diff --stat a^..b から試せ。
ちなみに git log --stat というのもできる。
0841デフォルトの名無しさん2011/06/02(木) 17:15:59.62
Diffでもstat使えるんですね
試してみます
0842デフォルトの名無しさん2011/06/02(木) 17:40:13.98
github落ちてね？
0843デフォルトの名無しさん2011/06/02(木) 18:04:47.07
>>842
調子悪かったな
ttp://twitter.com/github/status/76205632625188864
> Some users are having trouble accessing GitHub and pushing to repos.
いちおうオフィシャルに認識した出来事ではあった模様
0844デフォルトの名無しさん2011/06/02(木) 18:41:40.08
.macとはえらい違いだな
あっちは障害があったことを
まったく認識しとらんからな
0845デフォルトの名無しさん2011/06/02(木) 20:38:05.17
まんこまんこ

Github に10まんこタグをpushすると俺がblame受けかねないから思いとどまったが
なぜ大量のタグ(つかannotated tagじゃないから refs な)でGitが窒息するのか
原因と大まかな対策はわかった。
おれ、ちにてえのかなあ。

出典「なんでもおまんこ」谷川某
0846デフォルトの名無しさん2011/06/02(木) 20:39:01.34
>>845
0847デフォルトの名無しさん2011/06/02(木) 22:59:48.23
滑ってる
0848デフォルトの名無しさん2011/06/03(金) 21:31:11.95
まんこまんこおっさんはどこ?
0849デフォルトの名無しさん2011/06/04(土) 18:43:12.63
Cygwin の Gitを使用しているのですが、EclipseやNetBeansで作成したファイルをcomittすると
create mode 100755 .classpath
みたいになってしまいます。
(UTF-8の場合？)

デフォルトで644にしたいのですが、どういう設定を行えばよいでしょうか？
0850デフォルトの名無しさん2011/06/04(土) 18:53:23.00
"git core.filemode"でググれ
0851デフォルトの名無しさん2011/06/04(土) 19:19:28.82
>>850
その設定はfalseにしているのですが、初回コミット時に755になってしまうのです…
0852デフォルトの名無しさん2011/06/04(土) 20:26:23.63
まんこまんこだけど、そこそこ安定している msysgit-1.7.5 のありかきぼん。
ぐぐって見つけた版はなんかヘンだった。

gitdir 拡張が使いたいので 1.7.5 以降じゃないと具合悪いんだ。
0853デフォルトの名無しさん2011/06/04(土) 20:32:04.20
そういやmsysgitの公式バイナリはまだ1.7.4なんだな
いつもながらの遅さだわｗ
0854デフォルトの名無しさん2011/06/04(土) 20:36:16.44
homebrew する必要があるかw
公式つーても永遠の preview か?

多量タグ対策(あえて略すがまんこ対策)もしないといけないから、この際自前で作るか。
0855デフォルトの名無しさん2011/06/05(日) 07:37:02.38
TDDのときにGitを使う上での便利な使い方とかありますか？
0856デフォルトの名無しさん2011/06/05(日) 17:33:47.67
>>855
こっちのほうが良いと思われ

【バグ管理】 BTS使ってる？【追跡】 3
http://hibari.2ch.net/test/read.cgi/tech/1244347242/
バージョン管理システムについて語るスレ8
http://hibari.2ch.net/test/read.cgi/tech/1295493964/


0857デフォルトの名無しさん2011/06/05(日) 21:24:23.86
フックスクリプトとかそういう話を期待してんじゃね？
0858 忍法帖【Lv=6,xxxP】 2011/06/08(水) 14:24:10.18
おまえら、ちょっと教えてくださりませんか。


gitを5人でつかっている。全員中央リポジトリーにpushする
タイプの運用で、俺がなぜかテストおよび本番環境へのソース
管理者になった。orz

開発者は各自自分の環境で、プログラムをつくって設定ファイルで
差を吸収している。

なぜか、このプロジェクトのきまりで設定ファイルをignoreに
入れることができない。

このため、頻繁に設定ファイルがgit addされcommitされて
他人に伝播してしまう。git rm すると、設定ファイルが飛ぶので
開発者から文句がでる。

こういうときは、どうしたらいいんだ?

いまの俺の解は、設定ファイルがぶっこわれたら、
git管理外の自分の設定ファイルをコピってくる。
だが、もうちょっとなんとかならんか。
0859デフォルトの名無しさん2011/06/08(水) 14:31:26.04
> なぜか、このプロジェクトのきまりで設定ファイルをignoreに入れることができない。
管理者になったなら管理者権限でこのルール変えちまえｗ
0860デフォルトの名無しさん2011/06/08(水) 23:02:38.84
>>858
プログラマ別に固有のリポジトリ/リモートブランチ持たせて>>858がmasterにマージすれば？
ignoreできないのもアホすぎるけど、各プログラマが自分で判断してマージする能力を持ち合わせてないように見える。
0861デフォルトの名無しさん2011/06/09(木) 03:30:08.08
別人だけどついでに質問させてもらっても良いかな？

空の設定ファイルを管理対象にしてるんだけど、ローカルで動かすときには編集しないといけない
(例えばIDとかパスワードみたいなものを入力しとかないといけない)。

こういうファイルについてはどういう設定で運用すれば良いのでしょう？

自分用に更新したファイルをコミットせずにおいておくと枝分けたり移動したりするとき邪魔だし
コミットしてしまうと間違えてpushしてしまわないかmergeする度気にしないといけないしで。
たまーに設定項目増えたりするのでexcludeで指定するのも問題あるかなあ、と。
0862デフォルトの名無しさん2011/06/09(木) 04:50:08.35
>>861
雛形のファイル(例えば config.yml.sample)を管理対象にして、
ローカルでは雛形をコピーかつ編集したもの(例えば config.yml)を使う、
という感じ？
0863デフォルトの名無しさん2011/06/09(木) 06:55:00.49
Git使ってて必要のない変更までコミットしてしまうってのが
まずわからん

特に確認せずに、
いつもすべてコミットしちゃってる人ばかりなのか？
0864デフォルトの名無しさん2011/06/09(木) 07:41:58.62
yes
0865デフォルトの名無しさん2011/06/09(木) 10:13:10.50
ディレクトリごとコミットしてしまう人は、他のシステムでは稀に見る
gitでそれを毎回するにはどうやればいいのかまでは知らない
0866デフォルトの名無しさん2011/06/09(木) 11:52:36.35
gitだろうが何だろうが、余計な変更があったら邪魔なのには変わりないと思うが。
0867858 忍法帖【Lv=7,xxxP】 2011/06/09(木) 12:32:49.02
>859
俺に指揮命令権があるなら、管理者権限でやるんだが、めんどくせえことに
指揮命令権は別のところにあって、抗命はなしな orz.

>860
鋭いな、gitがはやりで覚えてほしいから、2名しかgitつかったことないのに
プロジェクトで使って覚えろだそうだ。3名には, 最低限, git add, diff,
commit, push, pull だけは覚えてもらった。いまはmasterブランチしかなくて
gitをわかっているやつだけが, branchと, submoduleを活用している。残り3名
にはブランチは、これから概念と実践を教えないといかん。

merge masterだけの仕事じゃなくて、programmingもやらんといかんのだが死ねる。

# gitでhttpとsshの両方でリポジトリを共用できますなんて、言わなきゃよかった。
# 雉も鳴かずば撃たれまいに。
0868デフォルトの名無しさん2011/06/09(木) 18:44:44.47
自分で覚えようとしない人に覚えさせるってのはだいたいうまくいかない
0869デフォルトの名無しさん2011/06/09(木) 23:45:14.56
自分で覚えようとしない人はこの業界自体あれだよな…
0870デフォルトの名無しさん2011/06/10(金) 00:19:08.60
>>862
ああ、確かにそうするのが適切かもしれませんね。
sampleファイルの名称変更はビルドとかデプロイとかの中で行うわけですね。

0871デフォルトの名無しさん2011/06/10(金) 00:24:38.04
というかgit ignore禁止に理由が知りたい
0872デフォルトの名無しさん2011/06/10(金) 01:25:37.34
>>871
そんな設定して誤爆したら困るじゃないか
責任取れるのか？
0873 忍法帖【Lv=7,xxxP】 2011/06/10(金) 01:41:28.21
>866
プログラマーがすべて、866みたいに注意深い人間なら、
デスマももうすこし減ってもいいはず。

それは、さておき, git commit -a を覚えると、やるみたい。

いきなり開発環境でやるなって話だけど、まあ cloneはおまじない
init は教えてないから、こっちが悪いってのもあるか....l
0874 忍法帖【Lv=7,xxxP】 2011/06/10(金) 01:48:53.32
>868
それは、そのとおりなんだが。gitを知らない人も、
オレも生き残りたい。

>871
おれも知りたい。

hogefuga.yml.sample とかつくって, hogefuga.ymlをgit rmして
再スタートできたらなあ。プロジェクトの最初からそうしてくれて
いたら.... ってグチってもなんとかならんな。
0875デフォルトの名無しさん2011/06/10(金) 01:59:28.88
git commit -a したところで untracked なファイルはコミットに含まれないはずだけど。
0876デフォルトの名無しさん2011/06/10(金) 02:03:08.14
・そうしないと管理工数が増えて実開発時間が減ります
・リリース時にミスって顧客に迷惑かけるリスクが増えます
とかってプロマネの立場にたった抗弁でルールを変えてもらったほうがいい
0877デフォルトの名無しさん2011/06/10(金) 02:11:51.35
どっかコンフリクト起こした時点で開発ストップするがな。
pushがrejectされても気づかなさそう。

普段使うコマンドっつーと何があるっけ
git status
git log --all --graph
git add
git commit -a
git commit -a --amend
git pull
git push
git branch
git checkout -b hoge
git checkout -f
git reset HEAD
git mv
git rm
git grep
git rebase
git merge
git mergetool
git cherry-pick
git stash
git show --name-only
git bisect
git blame hoge
...

結構色々あるな…
0878デフォルトの名無しさん2011/06/10(金) 02:33:39.98
>>872
例えばどんな誤爆？
0879デフォルトの名無しさん2011/06/10(金) 08:32:43.27
手をかけようとするのをやめな
事故を起こさせて困らせてから、それを解決しろ
どうせ誰も衝突や消失や手戻りの手痛い経験がないんだろ
なんのために存在するか理解できていないものは、「おまじない」になって永遠に理解されない
0880デフォルトの名無しさん2011/06/10(金) 09:21:49.29
活発なオープンソースプロジェクトを独自変更で追いかけて行く（もちろんこっちの変更は取り込まれない）
てのを実際にやったら、ほとんどの上位コマンドとGitの仕組みが理解出来ると思うな。
ついでに並行してsvnで同じ事やらせたら分散型の有用性も実感できる。
0881デフォルトの名無しさん2011/06/12(日) 01:30:01.95
Windows上で、Eclipseで作ったjavaファイルをCygwin Git で管理し始めました。

> create mode 100755 xxxx.java
となるのが気持ち悪いのですが、皆さんはどうされているのでしょう？
逐一chmodしているのでしょうか、それとも放置？
0882デフォルトの名無しさん2011/06/12(日) 05:29:17.11
>>881
/etc/fstabにnoacl,notexecでどうだろう
どんな副作用が出るかは知らない
0883デフォルトの名無しさん2011/06/12(日) 10:01:54.08
一般公開部分と非公開部分があるプロダクトを扱うことになったんだけど、
・リポジトリAには公開部分を置いて一般公開
・リポジトリBには非公開部分を置いて適当な認証を入れてアクセス限定
という運用はgitでできるでしょうか？

0884デフォルトの名無しさん2011/06/12(日) 12:10:44.39
>>883
Aにhttpもしくはgitでのreadonlyサービスを置く。
とにかくAに対してBの非公開部分を晒さないように *運用に気をつける*
Bはsshとかで好き放題やってくれ。
おまけ。Aにpushできる人を、ヘマをしでかさない人たち(いわゆるリリースマネージャ)に限定。

でいいんではないか? さしあたっては A をGithubなどで運用するケースを考えてみるとよい。
0885デフォルトの名無しさん2011/06/12(日) 12:55:11.58
tarballでのリリースでなくてリポジトリの公開か。
コミットログにも注意しないとなｗ
0886デフォルトの名無しさん2011/06/12(日) 20:06:36.25
>>883
プロダクト毎にリポジトリを分けようとすると混乱する。
リポジトリは公開/非公開で分けて、パッケージングは別にすればいい。
0887デフォルトの名無しさん2011/06/12(日) 23:52:37.48
>>884-886
回答どうもです

大元は同じコードなので、公開用と非公開用でブランチを割って
それぞれリポジトリA、Bみたいな感じでいけそうかな、と思います
0888デフォルトの名無しさん2011/06/13(月) 01:14:47.45
>>882
ありがとうございます！
その単語でググったら色々情報ヒットしましたので参考にします。
0889デフォルトの名無しさん2011/06/15(水) 12:22:11.41
まんこまんこだけど、まんこ(aka 100k refs)の話題をMLに投げてみたら、意外な方向に話が脱線してる。

要約「git notesの逆引きを充実させよう」
0890デフォルトの名無しさん2011/06/16(木) 21:37:28.88
会社でcvs使ってるんですけど、
リポジトリをsubversionに変換して（他のメンバー向け）、
（自分だけ）git-svnかますのって実用的でしょうか
0891デフォルトの名無しさん2011/06/16(木) 22:44:21.90
~/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
0892デフォルトの名無しさん2011/06/16(木) 23:31:54.16
>>891
あなたが原因だと思う
08938912011/06/17(金) 07:18:00.57
もっと具体的にお願いします！
0894デフォルトの名無しさん2011/06/17(金) 17:28:41.97
gitもこういうユーザが増えてきたってことか？
0895デフォルトの名無しさん2011/06/17(金) 17:47:34.45
>>893
バージョン管理システム自体を使うのが初めて？
0896デフォルトの名無しさん2011/06/17(金) 21:57:06.07
ヒント: hint
0897デフォルトの名無しさん2011/06/17(金) 22:22:18.04
エラー：3036a55戻すことができませんでした... 3
ヒント：競合を解決した後、訂正後のパスをマーク
ヒント："RM<paths>をgitの'追加<paths>をgitの'かで
ヒント：ととの結果をコミットするには、"コミットgitの"
0898デフォルトの名無しさん2011/06/17(金) 23:58:23.63
お祭り会場
https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac
0899デフォルトの名無しさん2011/06/18(土) 01:36:43.20
>>898
All your /usr are belong to us.
0900デフォルトの名無しさん2011/06/18(土) 06:48:11.71
/usr 配下に重要なファイルをインスコするOSは傍流
0901デフォルトの名無しさん2011/06/18(土) 11:38:54.21
>>900
/usr/homeがあるFreeBSDのことか
0902デフォルトの名無しさん2011/06/18(土) 12:53:47.73
>>901
何を言うか、FreeBSDはpackageから/usr/localにインスコするではないか
0903デフォルトの名無しさん2011/06/18(土) 12:54:21.53
…あれ、なんかすごいボケてたので↑はなしでｗ
0904デフォルトの名無しさん2011/06/18(土) 19:56:59.66
>>895
初めてです
0905デフォルトの名無しさん2011/06/20(月) 08:37:35.99
>>904
そうですか
それではまず服を脱ぎます
0906デフォルトの名無しさん2011/06/22(水) 18:32:18.48
入門Gitを斜め読みしています。(←難しくてぜんぶは理解できない...)

「トピックブランチで作業しているときに、
　トピックとは関係のない変更を取込むのは良くない」
といったことが書かれていたと思います。

私はブランチからmasterへのマージに際しては、
ブランチで
　　git rebase master
してから、
masterで
　　git merge ブランチ
とやっていたのですが、
これはマズいってことでしょうか?

そのようにしないと、
マージコミット
(これはどこそこブランチからマージされました とかいうログだけのコミット)
ができてしまって気持ち悪いなあと思っていたのですが...
0907デフォルトの名無しさん2011/06/22(水) 20:38:59.46
>>906
私も勉強中なので間違ってるかもしれませんが...

p.106ページの記述は
トピックごとにブランチ切ろう、ということを言っているだけであって、
トピック作業完了後rebaseすることの是非について言及しているわけではないと思います。

p.118の「リベースでまとめる」というのが>>906で記載されている方法に該当し、
特に非推奨の方法でもないと思います。

自分は
> (これはどこそこブランチからマージされました とかいうログだけのコミット)
> ができてしまって気持ち悪い
の場合にはmerge --no-commit でマージした後、手動でコミットしています。
0908デフォルトの名無しさん2011/06/22(水) 21:03:03.14
>>906
何ページだったか忘れたけど、マージコミットを嫌うやり方もある一方で
どんどんマージするやり方もある、て書いてあるよ。
つまりrebaseしないのはバカって訳ではない。
例えばバグ修正してるのに余計なコミットを混ぜ混んでったらダメだ、ってことだよね。
0909デフォルトの名無しさん2011/06/22(水) 21:09:05.44
tortoisegitのtgitcache.exeのバグは治った？
ファイルハンドル？取りっぱなしになっちゃうやつ
0910デフォルトの名無しさん2011/06/22(水) 22:42:56.90
>>909
XP上のTortoiseGitで、ログウィンドウとかを閉じようとしてもなかなか閉じず、
やっと閉じたと思ったらTortoiseProc.exeが残ったままになるんだけど
同じバグかな？
0911デフォルトの名無しさん2011/06/23(木) 05:42:15.67
GitHub for Mac
http://mac.github.com/
0912デフォルトの名無しさん2011/06/23(木) 06:24:27.56
906です。
レスありがとうございました！
のちほど本と照らし合わせながら
きちんとレスを読ませていただきます！
0913デフォルトの名無しさん2011/06/23(木) 14:32:56.76
>>911
これどの層に需要あんの？
0914デフォルトの名無しさん2011/06/23(木) 14:36:49.76
>>913
まあ、ないよな
Macなんて誰も使ってないし
0915デフォルトの名無しさん2011/06/23(木) 14:41:47.29
>>914
おい俺はMac使ってるぞ

でも>>911の利用価値はサッパリわからんぞ
0916デフォルトの名無しさん2011/06/23(木) 14:58:29.46
Tower(これもGitクライアントアプリ)に興味を持つ人なら
>>911も試すんじゃないかな？
俺は試した。そっと終了したが。
0917デフォルトの名無しさん2011/06/23(木) 14:59:58.09
そんなにダメなのか
0918デフォルトの名無しさん2011/06/23(木) 15:10:26.28
Towerといい…なんでMacのGitアプリはCPU使用率がこんなに高いんだろう
HitoryをスクロールするだけでCPU100%越えるんだが
0919デフォルトの名無しさん2011/06/23(木) 18:08:07.34
>>918
新しい Mac を買えってことだよ。
0920デフォルトの名無しさん2011/06/23(木) 19:42:36.62
>>919
去年買ったモデルでも一緒です
0921デフォルトの名無しさん2011/06/23(木) 19:52:52.41
まんこ詩んだ？
0922デフォルトの名無しさん2011/06/23(木) 22:15:05.17
>>918
Macが重いのはPowerPC時代からの伝統だよ
0923デフォルトの名無しさん2011/06/23(木) 23:28:40.30
2chの人たちはMac派は少ないのか？。。。
私がフォローしているTwitter上の人たちや勉強会に参加してる人たちは
Macが多いけど。。。
0924デフォルトの名無しさん2011/06/24(金) 00:08:06.86
俺一応使ってるよ。
UTF-8-MACだったりとかファイルシステムが大文字小文字区別出来なかったりとか
いろいろ難点あるけどね…
0925デフォルトの名無しさん2011/06/24(金) 00:11:30.62
以前HFS+(Macのファイルシステム)でケースを区別するようにフォーマットし直したら、
市販ゲームの一部に動かなくなるもの(Civlization IV)があって断念した。
ゲームプログラム内の文字列部分を覗いたら、ファイルパスが全部大文字で
格納してあって、呆然としたわ。
0926デフォルトの名無しさん2011/06/24(金) 00:38:08.12
>>923
Macは使ったことあるけど、自分の用途ではLinuxのほうが速いし楽だし便利だし
という結論になった
0927デフォルトの名無しさん2011/06/24(金) 01:30:07.96
勉強会に出てるような人らって
UNIX系OSのノートPCとして使いたいから
WINじゃなくMac選んでるイメージ。
0928デフォルトの名無しさん2011/06/24(金) 02:22:13.40
そういえばおととしぐらいにOSSカンファレンス行ったら
会場の7割ぐらいがノートでメモとってて、さらにそのうち9割ぐらいがMacだったな。
ステッカーベタベタ貼ってるようなヤツも居た。
0929デフォルトの名無しさん2011/06/24(金) 07:08:58.54
twitter使いは猿が多いからどうしてもMac使いが多くなる
0930デフォルトの名無しさん2011/06/24(金) 07:29:56.35
Webやってる連中はOSXが便利だな。つかWindowsがダメすぎ。
0931デフォルトの名無しさん2011/06/24(金) 13:44:23.91
ＵｂｎｔやＣｅｎｔじゃだめなんかい？
0932デフォルトの名無しさん2011/06/25(土) 00:26:21.59
プライベートならSUSEが安定してていいな

仕事WinXP、自宅SUSE Linuxだった所に
最近業務のサブノートでMac Air使い始めたが
Win, SUSEより使い勝手悪くてワロタ
0933デフォルトの名無しさん2011/06/25(土) 02:54:23.13
>>932
SUSEとやらは聞いたことがなかったな
他のlinuxディストリと比べて何が違うの？git方面で
0934デフォルトの名無しさん2011/06/25(土) 12:01:19.35
>>933
統合環境としてのSUSEが便利なのであって、
gitというツールに着目したら他Linuxと大して変わらんぞ
0935デフォルトの名無しさん2011/06/25(土) 13:38:37.20
githubとか(自分で作ったものでもそうだと思いますが)、リモートのリポジトリに対して
git gc に相当することはできないのでしょうか？

リモートのブランチを削除したのですが、webブラウザからURLを直接指定すると
相変わらずそのブランチのコミットが参照できるのが気になりまして…
0936デフォルトの名無しさん2011/06/25(土) 15:26:52.73
しばし待て。もしかして活動履歴から当該ブランチのハッシュが消え失せるまでプルーンされなかったりしてな!

さすがによそのプロジェクトのハッシュを自分のURLから見ることはできないよな?
(Githubくらいだと、背後に超巨大クラウド共通Gitオブジェクトデータベースファイルシステムがありそうな気がして…)

余談。他プロジェクトのフォークではない大きなプロジェクトをプッシュしてたら無料分のソフトリミット超えちゃった。
圧縮される気配がないので、手元でrepack, Githubプロジェクトを削除・再作成, packされたオブジェクトをpush
したら、目論見通りGithubのプロジェクトを圧縮状態にできた。
もうすこしおかねもちになったら、こんなみみっちいことをせず課金拡張しよう。
0937デフォルトの名無しさん2011/06/25(土) 22:31:40.75
TortoiseGitって細かいバグが多くて嫌だわ
TortoiseSVNとかTortoiseHgはもっと安定しているというのに
0938デフォルトの名無しさん2011/06/26(日) 00:47:32.69
>>937
バージョンは？
0939デフォルトの名無しさん2011/06/26(日) 01:45:57.08
>937
TortoiseBzrも忘れないでくださいね
0940デフォルトの名無しさん2011/06/26(日) 20:20:31.27
亀gitはバグ対応速度も亀並みなんやな・・・
0941デフォルトの名無しさん2011/06/26(日) 20:24:00.39
日本語混じりのコミット(と、ログ)以外、コマンドラインで十分な体に飼いならされちゃったわい。
tgitcache.exe とかいう有害なプロセスは都度Killしてるよ。
09429372011/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が競合している行を表示しない
・ベアリポジトリでは使えない？（エクスプローラーでコンテキストメニューが表示されない）

一体どんな設計しているんだ！！
0943デフォルトの名無しさん2011/06/27(月) 12:39:04.75
tortoiseproc.exe は勝手に死んでくれるからまだマシw
(うざいダイアログ粒すのがメンドくさいけどな)
0944デフォルトの名無しさん2011/06/27(月) 14:08:11.78
わざわざ不安定版を探して文句付けてるサディストがいると聞いて
0945デフォルトの名無しさん2011/06/27(月) 23:14:01.16
ナイトリーにいちゃもんつけるとは
一体どんな神経しているんだww
0946デフォルトの名無しさん2011/06/28(火) 03:00:26.89
942じゃないが、いちゃもんつけちゃダメっていうなら何のためにナイトリービルド公開してるの？
0947デフォルトの名無しさん2011/06/28(火) 03:07:56.86
ここでバグ報告してどうする
09489422011/06/28(火) 03:12:10.44
>>944-945
ここで指摘してやらないと>>942に書いたレベルでリリースされかねないだろうが？
これまでのバージョン見る限りマジやりかねんわ
0949デフォルトの名無しさん2011/06/28(火) 04:50:11.49
ここでバグ報告してどうする
0950デフォルトの名無しさん2011/06/28(火) 07:57:17.66
英語書けないんだよ糞が
0951デフォルトの名無しさん2011/06/28(火) 11:17:10.58
英晤じゃ無きゃダメなんて書いてないだろ
堂々と日本語で書いてスルーされてこいよ
0952デフォルトの名無しさん2011/06/28(火) 12:09:51.63
中国語で書かれたBugzilla PRがフルボッコ(ただし同胞のフォローがすこし)ってのを見たことがある。
0953デフォルトの名無しさん2011/06/28(火) 22:49:42.76
>>942が日本語でも英語でもいいからBugzlllaにチケット挙げないかな
いずれでもフルボッコにされそうで観戦してみたい
0954デフォルトの名無しさん2011/06/29(水) 06:08:48.57
性格ねじ曲がった団塊みたいな意見ですね
0955デフォルトの名無しさん2011/06/29(水) 16:08:16.27
そうだね、セールスの電話で遊ぶクソジジイっぽいよね
0956デフォルトの名無しさん2011/06/29(水) 18:17:58.17
あれだけはマジで基地外じみている...
0957デフォルトの名無しさん2011/06/30(木) 22:13:46.91
eclipse のオマケの EGit はどのように使うのでしょうか。
USB メモリにある小説も管理できますか？
0958デフォルトの名無しさん2011/06/30(木) 22:16:31.09
俺の肛門も管理されています
0959デフォルトの名無しさん2011/06/30(木) 23:05:19.69
なんでわざわざEclipseのEGit使って小説管理するんだ
素直にmsysGit使うえお
0960デフォルトの名無しさん2011/07/02(土) 00:39:35.01
参考までに
http://kokucheese.com/event/index/13468/
0961デフォルトの名無しさん2011/07/02(土) 01:02:24.41
肛門集会と思ってうrl開いたのに…俺の肛門は閉鎖されちゃったよ。
0962デフォルトの名無しさん2011/07/02(土) 20:44:05.63
version 1.7.6 はいかがでしょうか
0963天使 ◆uL5esZLBSE 2011/07/03(日) 15:07:23.76
>>960
ハアァアァアァアァアァァァアァァァァァァァァァァァァァァァァア？？？？？？
気持ち悪い？
あ
0964デフォルトの名無しさん2011/07/03(日) 18:33:25.53
天使さん戻っておいでよ
0965デフォルトの名無しさん2011/07/05(火) 18:24:39.02
make test でエラーが出てしまったわい
それでも入れちゃうけど
0966デフォルトの名無しさん2011/07/06(水) 05:03:26.65
.
0967デフォルトの名無しさん2011/07/06(水) 05:08:56.07
git status
0968デフォルトの名無しさん2011/07/06(水) 12:14:46.86
git log
0969デフォルトの名無しさん2011/07/06(水) 12:55:35.79
git diff
0970デフォルトの名無しさん2011/07/06(水) 17:25:59.91
git commit
0971デフォルトの名無しさん2011/07/06(水) 18:19:26.29
git rev-parse --git-dir | xargs rm -rf
0972デフォルトの名無しさん2011/07/06(水) 18:27:03.83
おいやめろｗ
0973デフォルトの名無しさん2011/07/06(水) 18:43:40.66
こまめに別のメディアへのバックアップをしましょうね
0974デフォルトの名無しさん2011/07/06(水) 18:44:37.00
git clone --mirror
0975デフォルトの名無しさん2011/07/07(木) 04:02:38.42
git revert
0976デフォルトの名無しさん2011/07/07(木) 09:04:08.90
git rerere
0977デフォルトの名無しさん2011/07/07(木) 10:08:15.83
git odekakedesuka
0978デフォルトの名無しさん2011/07/07(木) 14:07:54.86
rerereはこのまえちょっと便利に感じた。
0979デフォルトの名無しさん2011/07/08(金) 01:25:46.03
一度に複数の機能を追加してしまった場合に、
comit を別々にしたい場合、どうやればいいですか？

たとえば
a.c　b.c　c.c　の３ファイルがあったとして
a.cは関数A０（）と関数A１（）を変更
b.cは関数B０（）と関数B１（）を変更
b.cは関数C０（）と関数C１（）を変更
と、複数箇所を変更したとします。

しかし、これらが変更点の全ては関連してなくて、関連してるグループは２つに分けられ場合です。
つまり、
A０（）とB０（）とC０（）をグループG０とし、
A１（）とB１（）とC１（）をグループG１とした場合、G０のコミットと、G１のコミットは別々にしたいと考えるのが普通です。

そこで、これらを分けてコミットするために、自分の場合は
git diff a.c > a.patch として、diffパッチを得て、これを書き換えて A0.patch、A1.patchをそれぞれ作り、
同様に b.c と c.c でも B0.patch, B1.patch、 C0.patch, C1.patch としてパッチを作り、
これらパッチを用いてグループG０に相当する変更のみの状態を作り git commit し、
その後グループG１の状態も追加して git commit することで、グループG０とG１を別々にコミットするとう方法を行ってます。

これはすごく面倒なので、もっと簡単な方法は無いでしょうか？
複雑に混ざりあった変更から、コミットしたい変更だけ抽出して、任意に個別に（もしくはグループで）コミットする方法あったら教えてほしいです。
0980デフォルトの名無しさん2011/07/08(金) 08:04:18.44
git add -p
で、
まとまりのある変更点だけ選択(抽出)→ステージング→コミット
を繰り返せば良いと思います。
0981デフォルトの名無しさん2011/07/08(金) 14:16:34.72
そういう事態はgit add -i 使ってる

といってもあくまでうっかりのときだな
gitらしくちょっとした作業ごとに細かくブランチを切るようにしたら、いくつものコミットに分ける自体になりにくいよ
0982デフォルトの名無しさん2011/07/08(金) 14:32:26.43
>>881
modeを無視するgit configの設定があったはず
filemodeだったか
0983デフォルトの名無しさん2011/07/08(金) 18:16:44.69
git stash も悪くないよ。
0984デフォルトの名無しさん2011/07/08(金) 19:09:04.90
git add -iの存在を忘れていたなあ。
-pしか使ってなかった。
0985デフォルトの名無しさん2011/07/08(金) 19:35:45.94
>>982
その設定も行っているのですが、初回add時の属性は
ファイルシステムが認識しているものになるようです。
0986デフォルトの名無しさん2011/07/08(金) 20:39:09.00
Git のマスコットって森林破壊してるけど、あれって何か意味あるのかな？
0987デフォルトの名無しさん2011/07/09(土) 20:13:49.05
git init
0988デフォルトの名無しさん2011/07/09(土) 20:14:49.10
git gc
0989デフォルトの名無しさん2011/07/09(土) 21:19:33.36
git fsck
0990デフォルトの名無しさん2011/07/10(日) 10:06:30.23
git sucks
0991デフォルトの名無しさん2011/07/10(日) 20:05:56.67
git rebase
0992デフォルトの名無しさん2011/07/11(月) 12:34:56.42
git wants 次スレ
0993デフォルトの名無しさん2011/07/12(火) 01:56:15.62
Git 3
http://hibari.2ch.net/test/read.cgi/tech/1310403238/
0994デフォルトの名無しさん2011/07/12(火) 01:57:45.13
結局みんなGitに流れたよね
もう出始めの物は触らない事にする
0995デフォルトの名無しさん2011/07/12(火) 03:43:49.36
git ume
0996デフォルトの名無しさん2011/07/12(火) 07:22:34.77
>>993
おつぱい
0997デフォルトの名無しさん2011/07/12(火) 17:22:12.59
ume chau zo
0998デフォルトの名無しさん2011/07/12(火) 18:15:02.94
ume
0999デフォルトの名無しさん2011/07/12(火) 18:33:34.25
まんこタグはあきらめてまんこnotesに趣旨替え。

　　　　　↓↓↓ 1000取っていいから! ↓↓↓
1000デフォルトの名無しさん2011/07/12(火) 19:10:07.34
うめ
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。