Git 2

1 ：デフォルトの名無しさん：2010/09/14(火) 21:38:18

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

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

◆関連サイト
Git入門
http://www8.atwiki.jp/git_jp/

2 ：デフォルトの名無しさん：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/

3 ：デフォルトの名無しさん：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/

4 ：デフォルトの名無しさん：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/

5 ：デフォルトの名無しさん：2010/09/14(火) 23:53:53

あら、レスをそのままコピペしちゃった

6 ：デフォルトの名無しさん：2010/09/15(水) 00:02:15

Git - Fast Version Control System
http://git-scm.com/

7 ：デフォルトの名無しさん：2010/09/15(水) 02:27:25

『ぎっと』ですか『じっと』ですか

8 ：デフォルトの名無しさん：2010/09/15(水) 02:53:47

>>7
「ぎっと」
http://www.youtube.com/watch?v=4XpnKHJAok8

9 ：デフォルトの名無しさん：2010/09/15(水) 05:54:28

gは大文字なんだっけ？ロゴは小文字だけど。

10 ：デフォルトの名無しさん：2010/09/15(水) 08:37:16

名前としてはGit
コマンドとしてはgit

11 ：デフォルトの名無しさん：2010/09/15(水) 09:52:11

Git は何の略ですか？

12 ：デフォルトの名無しさん：2010/09/15(水) 11:27:41

Gitの略です

13 ：デフォルトの名無しさん：2010/09/15(水) 16:15:48

丁寧にありがとうございました

14 ：デフォルトの名無しさん：2010/09/16(木) 01:14:23

略じゃないw
gitどもめw

15 ：デフォルトの名無しさん：2010/09/16(木) 01:24:26

cogitoは何と読むべきでしょうか

16 ：デフォルトの名無しさん：2010/09/16(木) 07:57:47

>>15
cogito, ergo sum

17 ：デフォルトの名無しさん：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

18 ：17：2010/09/19(日) 22:13:10

branches/releases/はその下にバージョンを名前にしたフォルダが入っているのに、
branches/ogl-es/とbranches/SkinnedMeshはそのままファイルが入っています。
こんなブランチでも正しく扱う方法はあるんでしょうか

19 ：デフォルトの名無しさん：2010/09/20(月) 00:28:52

結局Windows用GitはmsysGitを入れればOKと色々なブログとかに書いてあるが、
実際にインストールするのはmsysGitではなく、ただのGitと書かれたインストーラを指しているけど、
ある人は「頭にmsysがついているGitを入れろ」といわれました。

何を入れればいいのかよくわかりません。

20 ：デフォルトの名無しさん：2010/09/20(月) 00:36:37

>>19
その人に聞けば良い

21 ：デフォルトの名無しさん：2010/09/20(月) 01:00:38

>>20
その人も違いがわからんといってました。
両方入れてみたところ頭にmsysが付かないほうはGUIがあるみたいでした。
ではmsysが付くほうのメリットは？
また両方入れて問題はないでしょうか？

とりあえず、Git（またはmsysGit）＋TortoiseGitの組み合わせにしようと思います。

22 ：デフォルトの名無しさん：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.
>

23 ：デフォルトの名無しさん：2010/09/23(木) 01:50:24

公式のDownloadにWindowsとMacの項目が増えたね

24 ：デフォルトの名無しさん：2010/09/23(木) 20:19:55

1.7.3キタんだけど、RelNotesのディレクトリ構造が変わってて、リンク切れしてるｗ
ttp://www.kernel.org/pub/software/scm/git/docs/RelNotes/1.7.3.txt

25 ：デフォルトの名無しさん：2010/09/25(土) 13:55:31

Gitについて前から疑問があるのですが、誰かご存知でしょうか？
gitはハッシュ値で管理するということですが、百万が一バッティングした場合、
何か対処法があるのでしょうか？

まあ、まず有り得ないとは思いますが、どの資料にもこの話が載っていないので……

26 ：デフォルトの名無しさん：2010/09/25(土) 14:06:54

蝙蝠本P42-44にsha1の衝突の可能性について書いてあるが
対処法は書いてない

27 ：デフォルトの名無しさん：2010/09/25(土) 14:08:15

まあ原理的には基本アウトだよね
完璧に手作業でサルベージするしかない
公開してたら全員に連絡とる
めどい

28 ：デフォルトの名無しさん：2010/09/25(土) 14:13:28

百万が一というより10^48が一だが

29 ：25：2010/09/25(土) 14:19:35

ありがとうございます。
やはり対策は打ってないか……Linusらしいといえばらしいですが。

30 ：デフォルトの名無しさん：2010/09/25(土) 15:05:01

ハッシュの万能さ加減がGitの要になってるから、
衝突したらお手上げだよね。

世界中の総力を結集すれば見つけることは可能だろうけど、
同一プロジェクト内でぶつかりさえしなければ問題には
ならないから、まあどうにでもなるんじゃないかな。

31 ：デフォルトの名無しさん：2010/09/25(土) 15:32:07

msysgit1.7.2.3とTortoiseGit1.5.3.0で使っていますが
Rebaseやcherry-pickを使うと、ダイアログを開いただけでTortoiseGitが落ちてしまいます。
Git Bashからなら使えるのですが、GUIが使えないのはやはり不便です。
ammendするときは前のコミットのメッセージが出るはずなんですが、何故か出なくなってます。

32 ：デフォルトの名無しさん：2010/09/25(土) 16:51:20

>>31
これってRebase.cherry-pickしようとしたら落ちる？それともした結果のもの？

33 ：デフォルトの名無しさん：2010/09/25(土) 16:54:08

>>28
えっと･･･もう少し具体的に
何分の一？

34 ：33：2010/09/25(土) 16:58:12

Googleに"10^48 in 日本語"と聞いても教えてくれない・・・

35 ：33：2010/09/25(土) 17:00:30

わかりました。
10^48=1000000000000000000000000000000000000000000000000=1極ですね。
納得

数の単位・日本の大きな数字の単位データ＞雑学データバンク
http://dorama.tank.jp/d/suujitanio.htm

36 ：デフォルトの名無しさん：2010/09/25(土) 17:01:53

SHA1は2の80乗個のハッシュを作ったらどれか1個だけが50％で被る

37 ：デフォルトの名無しさん：2010/09/25(土) 19:46:26

つまり、とりあえず生きてるうちにそういう状況にぶつかれる可能性はほとんどないってことだろwww

38 ：デフォルトの名無しさん：2010/09/25(土) 19:59:46

確率論とは悲惨なもので、どんなに天文学的な確率を弾き出してても実際に起こるときはやっぱ起こる
カーネルのソースコードで起きないかなーとちょっと期待中

39 ：デフォルトの名無しさん：2010/09/25(土) 20:02:52

どう見ても、ハードディスクやマシンの故障とかを気にするべきw

40 ：デフォルトの名無しさん：2010/09/25(土) 20:08:29

DAGだから親がいないみなしごになるだけじゃ？

41 ：デフォルトの名無しさん：2010/09/25(土) 20:52:59

どうなんだろ、オブジェクトIDがダブった時点で
・既にあるのおかしい！と異常終了
・気付かずにそのまま使ってぶっ壊れる（blobなのにcommitが出てきたり
　すると異常に気付くような気もする）
・リモート同士でダブった場合、push先のbareリポジトリでぶっ壊れる？
ぶつかったのが両方共同じオブジェクトタイプだったりすると、
けっこう面倒なことになりそうかも。

関係ないプロジェクト間ではいつか出そうな気もするけど、
Linuxカーネルのリポジトリで何年後かに出るようなことは…
強運の持ち主がけっこう居そうだから、意外に出ちゃうかもｗ

42 ：デフォルトの名無しさん：2010/09/25(土) 21:05:19

一番リビジョンが多いのはやっぱりLinuxカーネルなのかな？
ハッシュ衝突したらニュースになるのかな？

43 ：デフォルトの名無しさん：2010/09/25(土) 21:09:36

>>42
それはニュースになるでしょう。
カーネルがどうこうではなく、sha1ハッシュの脆弱性が考えられるから。

44 ：デフォルトの名無しさん：2010/09/25(土) 21:19:00

すでにあるのと重複チェックは重くてできないか。
gitは全部のリビジョンを持ってこなくても良いから意味ないか。

45 ：デフォルトの名無しさん：2010/09/25(土) 21:27:35

>>43
いや脆弱性も何もカブるのは単純な確率の問題
カブらないことは原理的にありえない
脆弱性とか関係ない

もし意図的にハッシュ値を同じにしたというのなら、昔ならニュースになった
今はSHA-1は既に現実的な時間で破られてるからニュースにもならない

46 ：デフォルトの名無しさん：2010/09/25(土) 21:30:27

>>45
俺もあなたと同じこと思ったけど（書き込みまでしそうになったｗ）
>>43の人もそれは分かってるから、「脆弱性が考えられる」なんて
まわりくどい書き込み方したんでないの？
「現実的にはほぼ衝突しない、だが衝突した、これは果たして
本当に"運が悪かった"だけなのか？」という意味でニュースになるだろうと。

47 ：デフォルトの名無しさん：2010/09/25(土) 22:01:05

ハッシュのコリジョンよりgitのバグの方を気にしろ、って事だろう
隕石が脳天直撃する事より交通事故を心配しろみたいな感じで

48 ：デフォルトの名無しさん：2010/09/25(土) 22:09:38

hgも同じ感じのハッシュだけど、bzrはコミットユーザと時間とハッシュの連結みたい

49 ：デフォルトの名無しさん：2010/09/25(土) 22:41:46

>>47
正に杞憂

50 ：デフォルトの名無しさん：2010/09/25(土) 23:20:45

もし衝突したら、話題にはされるだろうけど、
commit log にしろ、ソースそのものにしろ、
改行 or スペース一個足せば、
解決するんでないの?

51 ：デフォルトの名無しさん：2010/09/26(日) 00:17:35

可能性がゼロじゃないってだけで不安になるのは職業病だから仕方ないと思うけど
現実的には気にするほどのことでもないんじゃね
数百匹のサルがでたらめにタイプしてシェークスピアの作品をどうこうみたいなもので

52 ：デフォルトの名無しさん：2010/09/26(日) 01:37:21

>>47
はははｗ

53 ：デフォルトの名無しさん：2010/09/26(日) 01:38:37

>>50
落ちるかもわからない隕石は放っておいて、
もし落ちたら落ちたでその後処置すればいいわけですね、わかります

54 ：デフォルトの名無しさん：2010/09/26(日) 02:39:26

人間いつか死ぬんだし

55 ：デフォルトの名無しさん：2010/09/26(日) 08:24:45

>>53
よくわかってんじゃねーか

56 ：デフォルトの名無しさん：2010/09/26(日) 08:47:22

ム板に来ると変なのが出てくるけど、文字コードの話はまだ？

57 ：デフォルトの名無しさん：2010/09/26(日) 08:51:22

衝突するかもしれないようなものを衝突しないとして設計しているのはバグのある
設計であることは間違いないわけで、確率的にほとんどないからそれでいいんだ、
というのはコードを書く人間の態度しては良いとは言えない。
実際bzrのような回避策もあるわけだし。

58 ：デフォルトの名無しさん：2010/09/26(日) 08:55:55

>>57
bzrってハッシュにユーザ名と時間くっつけてるんでしょ？
衝突の可能性としては同じだと思うんだけど。

59 ：デフォルトの名無しさん：2010/09/26(日) 09:13:40

ハッシュ値が一度でも被ったなら、そのシステムの「被り回避」は信用ならない
絶対に被らないか、天文学的な確率でいつか絶対に被るか、どっちか

被ったらどうせそこで止まるんだし手作業でなんとかしようぜ、というのがgit
ほんのちょっと(SHA1の計算されたランダム性に比べたら本気でほんのちょっと)ハッシュ値を長くしただけで
「これで大丈夫対策ばっちり」とか無邪気に信じてるのがbzr

60 ：デフォルトの名無しさん：2010/09/26(日) 09:18:49

てゆーかだな、
ファイルパス＋所有者名＋タイムスタンプではどうにも区別できないからこそハッシュ値を使用してるんであって、
わざわざハッシュ値にファイルパス＋所有者名＋タイムスタンプをいまさらくっつけても
ハッシュ値強度はほとんど何も変わらない
ハッシュ値としてユーザーフレンドリーであるという以上の意味はない

61 ：デフォルトの名無しさん：2010/09/26(日) 09:19:24

ム板らしくなってきました。
bzrはbzr log --show-idsでないと出てこないみたい

62 ：デフォルトの名無しさん：2010/09/26(日) 12:19:42

ハッシュ値の件だけど、将来のバージョンでSHA-256とかが使われる余地はあるんだろうか
全ユーザがそのバージョンに乗り換えないと使い物にならないだろうから絶望的な気がするが

63 ：デフォルトの名無しさん：2010/09/26(日) 12:24:02

それはGitの次のアーキテクチャだと思う
実際上、Gitで衝突はまず起こらない
というか起きた人は挙手して欲しい所存
たぶんインタビューとか受けられるぞw

64 ：デフォルトの名無しさん：2010/09/26(日) 13:38:59

gitに限らず、普通にハッシュが衝突したってだけでそれなりの話題になるのは必至だろうな

65 ：31：2010/09/26(日) 18:12:35

>>32
しようとしただけで落ちます。
ログ一覧からRebase(cherry-pick)を選択しただけで落ちます。
Git1.7.1なら大丈夫みたいなのでしばらくこれで行こうかと思います

66 ：デフォルトの名無しさん：2010/09/26(日) 18:51:14

>>65
した結果が見えているんなら、TortoiseGitのバグだろうね。

67 ：デフォルトの名無しさん：2010/09/27(月) 10:12:59

git svnをproxy環境下でも使う方法わかった
gitの設定ではなく、$HOME/.subversion/serversを変更しないといけなかったらしい

http://www.mail-archive.com/[email protected]/msg00745.html

68 ：デフォルトの名無しさん：2010/09/27(月) 19:30:55

>>60
同じ所有者が同じタイムスタンプでcommitする操作なんてまずしないから
十分有効な回避策のはずですが。
git信者ですか？

69 ：デフォルトの名無しさん：2010/09/27(月) 19:35:08

>>68
commitの--dateというオプションと
GIT_AUTHOR_DATE, GIT_COMMITTER_DATE 環境変数で時間なら操作できます

70 ：デフォルトの名無しさん：2010/09/27(月) 19:40:17

rebaseだと時間順に並ばないから意味無いんだけどね

71 ：デフォルトの名無しさん：2010/09/27(月) 21:39:47

>>68
「まずしない」ということが何を意味するのか、ハッシュ値の衝突が
「まずしない」と比較してどうなのか、考えてみよう。

72 ：デフォルトの名無しさん：2010/09/27(月) 21:48:32

フロッピーの時間操作なんかまずしないもんね

73 ：デフォルトの名無しさん：2010/09/27(月) 21:58:58

ユーザ名+時分秒+ランダム数字4ケタくらいでまず重複しない

という発想の人はまれによくいる

74 ：デフォルトの名無しさん：2010/09/27(月) 22:00:55

ぐへへ・・・タイムスタンプを衝突させてやるぜ

75 ：デフォルトの名無しさん：2010/09/27(月) 22:03:13

ユーザー名とタイムスタンプで十分なのならハッシュ値なんて面倒なものそもそも使わないと何度でも何度でも言う

76 ：デフォルトの名無しさん：2010/09/27(月) 22:11:47

というか、
　充分にランダムなハッシュ値Aを3桁くらい伸ばしとく
と
　ハッシュ値Aが衝突を起こした場合（に備えて）、ハッシュ値にユーザー名とタイムスタンプを付加してID値とする
はおおむね乱数ハッシュ値の強度的に同じだということに気づけない人がいるというのが
やっぱ日本の数学教育駄目だなあとかちょっと思う

ハッシュ値のこのbって書いてある部分を1個cにしたハッシュ作って、と言われても出来ないだろ
でも「このユーザー名全部大文字にして」は文字列操作ですぐ出来るだろ
そんなのハッシュじゃねえんだよ
ハッシュの唯一性を1ミリも強化できないんだよ

77 ：デフォルトの名無しさん：2010/09/27(月) 22:20:22

gitは日本で作られたの？
主要コミッタは日本人だそうだけど

78 ：デフォルトの名無しさん：2010/09/27(月) 22:26:28

そもそも外国製
日本人の人がその中で頑張った

79 ：デフォルトの名無しさん：2010/09/27(月) 22:46:19

>>76
意図的にできるということと、偶然そうなってしまうということの違いを理解できない
人がいるということに問題を感じる。

80 ：デフォルトの名無しさん：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

というような処理をはできないのでしょうか？
よろしくお願いします。

81 ：デフォルトの名無しさん：2010/09/28(火) 00:35:48

>>80
Git的には意味不明だから、日本語で詳しく書くか、チュートリアルぐらい読んだ
ほうが良いと思う。

82 ：デフォルトの名無しさん：2010/09/28(火) 00:41:06

>>80はbzrの共有リポジトリを言っているんじゃないかと思う

83 ：デフォルトの名無しさん：2010/09/28(火) 01:27:04

>>81,82
返答ありがとうございます。

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

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

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

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

>>82
Bazaarはディレクトリごとに管理してるんですね。
こっちならこのようにできそうな気が・・・。
少し調べてみます。

84 ：デフォルトの名無しさん：2010/09/28(火) 01:29:36

>>77 >>78
日本人と言っても在米１５年以上の在米邦人だ。
現在はGoogle社員。

85 ：デフォルトの名無しさん：2010/09/28(火) 02:27:47

>>83
Gitosisみたいなのでホスティングすればそういうのできるよ。

>>84
どっかのプロフィールではTwin Sun所属ってことになってたと思うんだけど、
ヘッドハントされたのかな。

86 ：デフォルトの名無しさん：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リポジトリの履歴がかなりメチャクチャになってしまうのですが、
上手く持ってくるような方法はないでしょうか？

87 ：デフォルトの名無しさん：2010/09/28(火) 04:55:24

>>83
>>85 じゃないけど、github使う(privateや容量増は有料だけど)のもいいね
githubはユーザーごとに簡単にリモートリポジトリもてて
管理用のユーザーかリポジトリ作っておけば、そっちにも成果をマージできるでしょ

あとは、どこかのサーバーに中央リポジトリ用意して、
各個人ごとにリモートブランチきって突っ込むとかｗ

88 ：デフォルトの名無しさん：2010/09/29(水) 01:53:46

タグ一覧するコマンドって無いのかな？

89 ：デフォルトの名無しさん：2010/09/29(水) 02:38:58

>>88
git tag

90 ：デフォルトの名無しさん：2010/09/29(水) 12:16:25

gitはSSHと組合せて使っている人が多いと思いますが
SSHの秘密鍵生成には確率的素数判定法を使っているはず:-)

91 ：デフォルトの名無しさん：2010/09/30(木) 13:27:41

v1.7.3.1きた。stash が壊れてたらしい。

92 ：デフォルトの名無しさん：2010/10/02(土) 18:29:39

告白というか、一緒に下校してほしい、みたいな感じ。
お互い徒歩通学で家まで１時間ぐらいかかるんだわ。
昨日からその子のことを下心でしか見てない自分が悲しい

93 ：デフォルトの名無しさん：2010/10/02(土) 18:30:38

これはひどい誤爆…
すいません

94 ：デフォルトの名無しさん：2010/10/02(土) 18:45:04

甘酸っぱいのうｗ甘酸っぱいのうｗｗ

95 ：デフォルトの名無しさん：2010/10/02(土) 18:52:07

gitのスレタイで来たのなら、高度な誤爆

96 ：デフォルトの名無しさん：2010/10/02(土) 19:07:47

>>93
絶対に許さない

97 ：デフォルトの名無しさん：2010/10/02(土) 20:14:11

gitってあほ、ぼけ、間抜けって言う意味なんだねｗ

98 ：デフォルトの名無しさん：2010/10/02(土) 21:16:07

なんだ俺のことか

99 ：デフォルトの名無しさん：2010/10/02(土) 22:06:47

お前は間抜けなんかじゃないよ。自信を持とう。

100 ：デフォルトの名無しさん：2010/10/02(土) 22:13:07

そうだ、お前は間抜けでも歯抜けでも毛抜けでもない！

101 ：デフォルトの名無しさん：2010/10/03(日) 13:49:29

欝だ死のう

102 ：デフォルトの名無しさん：2010/10/07(木) 14:21:35

話の流れをブッタギル様ですまん。

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

つかまとめあげたパッチを強制的にファイル単位にバラす方法知らん?

103 ：デフォルトの名無しさん：2010/10/07(木) 20:08:27

git commit -m '#!/usr/bin/hogeを#!/usr/local/bin/hogeに変更' とか？
同様の変更ってことはある単一の意図でやったことだろうから
100個に分割するんじゃなく1個にまとめるべきなんでは

104 ：デフォルトの名無しさん：2010/10/07(木) 21:46:08

運用次第だと思うが、git推奨はどんなのだろう

俺の場合、コミットログがバラバラになる場合はコミットはまとめないけど、
それでもまとめない場合はブランチ名つけておけばいいんちゃうのかな

105 ：デフォルトの名無しさん：2010/10/07(木) 21:58:37

>>102
例えばそれが「インデントまとめて変更」とかだったら100ファイル一発でも
良いと思うが、100個のバグ修正だったら絶対に分けるべきだと思う。

俺の考えでは、誰かが分離したくなるかもしれない単位、で
世に出すのが良いのではないかと思う。

106 ：102：2010/10/08(金) 09:03:57

そゆ意味じゃ、テストスクリプト群への同様の修正なので、
100個のバグ修正ともいえるな。

107 ：デフォルトの名無しさん：2010/10/08(金) 11:54:56

そもそもなんで同じ内容のものを100箇所に鏤めて置くんだ？
普通共通のファイルを一個作ってincludeなりなんなりするだろ

108 ：デフォルトの名無しさん：2010/10/08(金) 13:05:29

テストプログラムに対するレビューは果たして必要か

109 ：デフォルトの名無しさん：2010/10/08(金) 13:31:46

>>108
スレ違い

110 ：デフォルトの名無しさん：2010/10/08(金) 14:01:22

わかった、じゃあスレ違いじゃない書き方にする。

>>109
他人のテストスクリプトに対してそういうケチを付ける気にはならないな、自分は。

111 ：デフォルトの名無しさん：2010/10/08(金) 14:02:25

っぷっ

112 ：デフォルトの名無しさん：2010/10/10(日) 17:17:16

rebaseしたら今いるブランチの最後のコミットだけ無くなった
どういう事なの・・・

113 ：デフォルトの名無しさん：2010/10/10(日) 17:22:58

はぁ・・・復元する方法ないのかな・・・

114 ：デフォルトの名無しさん：2010/10/10(日) 17:44:51

reflogすれば見つからないか？

115 ：デフォルトの名無しさん：2010/10/10(日) 18:57:14

>>114
！！あった！！
ありがとう！

116 ：デフォルトの名無しさん：2010/10/10(日) 22:39:25

>>112
ふつーは reflog でちまちま探すなんだけど、rebase する前にあらかじめ
git checkout -b b4rebase rebased みたいにくさびブランチを打っておくとよいぞ。

つか rebase がもっと柔軟にならんかね。って欲張りな悩みよね。

117 ：デフォルトの名無しさん：2010/10/10(日) 22:41:39

カキコついでに質問だが、カスケードしたブランチを一発で rebase するいい方法、ない?

master->foo-bar->baz->qux みたいなブランチを、一気に直線 rebase するような感じの。

118 ：デフォルトの名無しさん：2010/10/10(日) 22:50:43

>>116
rebase -i はけっこう柔軟だと思う。

>>117
普通に git rebase master qux じゃダメなん？

119 ：デフォルトの名無しさん：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
と同じ結果にならないよね?
各ブランチがレビュー待ちのパッチを含んでいると想像してくれ。

120 ：デフォルトの名無しさん：2010/10/11(月) 16:12:03

言い忘れ。かつ、各ブランチがそれぞれのマイルストーンを達成している。

121 ：デフォルトの名無しさん：2010/10/11(月) 16:32:54

>>119
それをコマンド一発でやりたいってこと？
branch.name.mergeを元にして動くスクリプトを書いても良いと思うけど、
mergeと違って、元がrebaseしてる場合はコンフリクトする可能性大だから、
複数ブランチを一気にrebaseかけるのは怖いな。
手動でやったほうが良いんじゃないかね。

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

なかなか上流に取り込んでもらえないと、rebaseでキレイに並べて
おきたい気持ちは分かるんだけど…

122 ：デフォルトの名無しさん：2010/10/12(火) 19:48:42

master ブランチにいるとき git merge origin で origin/master->master のマージが行われないのなんでだよ!

123 ：デフォルトの名無しさん：2010/10/12(火) 19:56:42

>>122
git pullなら省略できる（適切に設定されてれば）

124 ：デフォルトの名無しさん：2010/10/12(火) 20:46:28

すげー書き違え! まさにその git pull origin でカレントじゃない master の更新が行われず、
git push するたびに master について叱られるのだ。
master じゃほとんど作業しないし。

すまんこ

125 ：デフォルトの名無しさん：2010/10/12(火) 23:54:22

自演乙

126 ：デフォルトの名無しさん：2010/10/15(金) 10:32:34

TortoiseGitをプロキシ経由で使うのってどうやれば？
試しにSettingsでプロキシを有効にするよう設定してみましたが無理でした

Putty Fatal Error
Network error: Connection timed out

127 ：デフォルトの名無しさん：2010/10/15(金) 16:18:44

うちでは正常に動作するよ

128 ：デフォルトの名無しさん：2010/10/16(土) 01:11:54

PuttyってことはそれってPutty側で設定がいるんじゃ
外してるかも

129 ：デフォルトの名無しさん：2010/10/20(水) 09:00:47

git svn で取得したリポジトリにて git describe がタグ振らずに機能するといいなあ。

130 ：デフォルトの名無しさん：2010/10/23(土) 13:47:49

git commit -aを実行するとVimが起動します＞＜

131 ：デフォルトの名無しさん：2010/10/23(土) 13:49:33

git commit -aを実行するとjedが起動
します＞＜

132 ：デフォルトの名無しさん：2010/10/23(土) 13:54:48

git commit -aを実行するとパソコンが固まります＞＜

133 ：デフォルトの名無しさん：2010/10/25(月) 14:27:04

もしかして、日本語でログメッセージ書くとStashに失敗する？
TortoiseGit1.5.8.0とGit1.7.3.1で使っているけど、ときどき失敗する。
しかもGit Command Progressのダイアログでは、ログメッセージに日本語が入っていると文字化けして表示される。

134 ：デフォルトの名無しさん：2010/10/25(月) 14:32:37

なんかgit svnで取得したリモートブランチに対して、直接mergeをかけたら
svn側でしか変更してないはずなのにコンフリクトするんだけど、
もしかしてリモートブランチはマージ履歴持ってなかったりする？

git svn fetch #リモートブランチを更新
git merge --squash --no-commit git-svn #リモートの更新をmasterにマージ
# ここでコンフリクト

135 ：デフォルトの名無しさん：2010/10/25(月) 15:21:51

>>134
今のところSVNでgitのマージコミットを表現することはできないから、
dcommitする予定のブランチではmergeしちゃダメだよ。
まず今のブランチをgit svn rebaseでSVNに追随させないといけない、んだけど
うまくrebaseできなそう。。。
git checkout -b mergetest git-svn してcherry-pickで整形し直したほうが
良いかもしれない。

136 ：デフォルトの名無しさん：2010/10/25(月) 23:53:01

>>135
いや、svn側の変更をgitで追いかけているだけなんで、dcommitする予定はないんだ。
手元にはsvn fetchしているだけのリモートブランチ(デフォルト名のままgit-svn)と、
ローカルの変更込みのmasterがあるだけ。

cherry-pickしたほうがいいのかなあ。ありがとう。

137 ：デフォルトの名無しさん：2010/10/26(火) 03:20:57

no-ffつけるとかそういう話じゃなくてか

138 ：デフォルトの名無しさん：2010/10/26(火) 04:48:40

no-ffはsvnブランチ間のマージの話だったように思うけど……今度試してみる

139 ：デフォルトの名無しさん：2010/10/26(火) 07:04:26

>>136
>>134をよく見たら --squash してるけど、前回もそうしてた？
それならコンフリクトするのも分かるよ。
squashで別のコミットとして作り直してるから、次にマージする時には
また同じコミットが対象になってしまう。コンテンツの内容が近いなら
うまい具合にマージ出来るかもしれないが、失敗する可能性も高い。
これはgit-svnに限らないgitの話。
git log master..git-svn で見ると既にマージ済みのが出てくるんじゃないかな。

140 ：デフォルトの名無しさん：2010/10/26(火) 07:38:43

>>139
確かにgit log master..git-svnしたらsvn側の履歴が全部出てきた……。
svn側の複数の変更を、masterではひとつにまとめたかったんだけどなあ。
やってることはリモートブランチがsvnなだけでhttp://progit.org/book/ja/ch6-7.htmlと変わらないと思ってたんだけどなあ。

141 ：デフォルトの名無しさん：2010/10/26(火) 08:02:41

前回merge --squashしたところからの三点マージができればいいんだけど、
そもそもgitで三点マージを行うのがrebaseか……。

どうせsvn側でしか変更はないんだから-Xtheirsでも付けるかな……。

142 ：デフォルトの名無しさん：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他の配管コマンドでどうにかしたりする必要あり。

143 ：デフォルトの名無しさん：2010/10/27(水) 02:47:53

read-treeに-mなんてあったのか。次からそれでやろう。ありがとう。

144 ：デフォルトの名無しさん：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つのコミットになっていた件。
なんなんだこれは…

145 ：デフォルトの名無しさん：2010/11/02(火) 17:36:48

>>144
>>135

146 ：デフォルトの名無しさん：2010/11/04(木) 05:36:07

リモートリポジトリに真っさらなブランチをpush --forceしてしまいました
手元には元のソースは残っていません
復旧は不可能ですか？

147 ：デフォルトの名無しさん：2010/11/04(木) 06:20:02

>>146
まず手元のリポジトリで git reflog してみる。それで見つかるかも知れない。
手元に無くても、分散してるどこかにあるかも知れない。

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

あまりあり得ないと思うけど、空pushした後に git gc が実行されていると
ポインタだけじゃなくてオブジェクトも消えているので、もうダメぽ。

148 ：デフォルトの名無しさん：2010/11/06(土) 01:24:46

GitExtensions使ってる人いますか？
あれ、いつの間にか日本語対応しました？

149 ：デフォルトの名無しさん：2010/11/06(土) 13:56:34

そんなのあるのか、使ってみよ

150 ：デフォルトの名無しさん：2010/11/06(土) 23:49:36

過去の履歴を綺麗さっぱり消したいのですが可能でしょうか？
現在のHEADを１番目のコミットにしてしまいたいのです。
単純に.gitディレクトリを削除してinitし直せばいいのかな？

151 ：デフォルトの名無しさん：2010/11/07(日) 00:36:17

>>150
ほんとに綺麗さっぱりなら.gitを消してinitしなおすのが簡単だね。
微妙に残すのなら、git checkout --orphanというのがあるので
これを利用すればrootコミットから作れる。

152 ：デフォルトの名無しさん：2010/11/07(日) 03:02:04

なんか、こういうことをやりたい、ってのが先にある時にやり方が分からないことが多いのは
gitの思想によるものなのか、それとも単に分散バージョン管理に慣れていないからなのか、たまに分からなくなる。
特に、分散なんだからそれぐらいできてもよさそうじゃん、ってのができないとき…。

153 ：デフォルトの名無しさん：2010/11/07(日) 03:31:14

例えばどういうこと？

逆引き的なドキュメントが少ないという話であれば
ProGit一通りよむとかなり解決するが
http://progit.org/book/ja/

154 ：デフォルトの名無しさん：2010/11/07(日) 03:38:18

むしろgit使ってみて今までやりにくかったことが簡単にできてびっくりしたけど
Subversion使っていてこういう機能欲しかったんだ、というのがあったり
TortoiseSVNからコマンドラインに移行したのも理由だと思うが

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

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

155 ：デフォルトの名無しさん：2010/11/07(日) 03:59:41

gitは、もしPro Git（の日本語訳）がなければ、少しでも難しいことは
何もできなかっただろう、という気はする

156 ：デフォルトの名無しさん：2010/11/07(日) 04:25:12

便利そうなんだよなあ。
それはわかってるんだけど、
どうも Mercurial から移行できない。

157 ：デフォルトの名無しさん：2010/11/07(日) 04:25:50

Mercurialってどうなの？

158 ：デフォルトの名無しさん：2010/11/07(日) 05:02:34

Mercurial は分散で高速なんだけど凝ったことしなきゃ svn なんかとそんなに変わらない感覚で使える。
git は便利な分だけ覚えなきゃなんないことがある。ちょっと感じが違うよね。

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

Mercurial でいいや。とか思ってたんだけど、このスレ見てると、やっぱ git が気になってw

159 ：デフォルトの名無しさん：2010/11/07(日) 05:08:52

ほー。今度使ってみようかな

160 ：デフォルトの名無しさん：2010/11/07(日) 08:42:55

hgは基本機能は限定されているけど、hgに同梱されている拡張のMQを使えばほぼgitと同じことができる。
hgとgitは概念的にはかなり似ているけど、決定的に違うのがブランチの考え方。
hgの名前付きブランチがgitに無い。

161 ：デフォルトの名無しさん：2010/11/07(日) 11:59:47

>>160
名前付きブランチってどういう感じのもの？

162 ：デフォルトの名無しさん：2010/11/07(日) 12:30:21

> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのブランチにリビジョンの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。

163 ：デフォルトの名無しさん：2010/11/07(日) 12:35:01

すまん。肝心な所で間違った。

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

> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのリビジョンにブランチの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。

164 ：デフォルトの名無しさん：2010/11/07(日) 12:51:30

>>163
なるほど、なんか分かった。確かにGitはブランチの名前自体には意味を持たないので、
最初使い始めの頃はそこに戸惑った気がする。この変更ってどこから（どのブランチから）
来たんだろ？って思った時によく分からないんだよね。
マージコミットのログメッセージにブランチ名が書かれるから、gitkとかで視覚的に見れば
なんとなく分かるけど、それでもFast-forwardだったりすると完全に統合されちゃうから、
masterでやった作業なんだかtopicでやった作業なんだか、一見分からない。

165 ：デフォルトの名無しさん：2010/11/07(日) 12:55:13

俺も１人で開発する時はmercurialだな。
慣れてるからってのもあるが開発に全く無駄が入らない。
コミットを綺麗に整形したい時はgitを使う。

166 ：デフォルトの名無しさん：2010/11/07(日) 17:25:47

GitExtensionでgit rebase -i 相当のことをするにはどうすればいい？

167 ：デフォルトの名無しさん：2010/11/08(月) 03:02:41

Subversionのときはコミットミスっても気にならなかったが、
gitだと下手に直せるからつい気になるわ

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

cherry-pickするか別のブランチ名つけろ、というのはそうなんだけど

168 ：デフォルトの名無しさん：2010/11/08(月) 09:46:43

>>164
そこで git merge --no-ff

169 ：デフォルトの名無しさん：2010/11/08(月) 10:46:33

fast-forward の意味がいまだにわからない‥‥

170 ：デフォルトの名無しさん：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』と言います。

171 ：デフォルトの名無しさん：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した分を飛ばして解決したが他にいい方法合ったのか

172 ：デフォルトの名無しさん：2010/11/09(火) 02:47:58

分かった気がする
ブランチの方に進んだだけの状態と、
ブランチの方に進んで一方masterの方も進んでいる状態の
2パターンでmasterにマージしてみたら前者だけがfast-forwardって出たわ。
前者は別にマージする必要というか絶対コンフリクトしないから
ただポインタをブランチの先頭だったところにずらしました、ってことだな

173 ：デフォルトの名無しさん：2010/11/10(水) 17:09:04

git checkout の対象がブランチか、ディレクトリか判断つかないとき
git checkout dir/ とやってみたらディレクトリに反応して俺すげー
とおもってマニュアル見たら git checkout -- dir とすりゃよかったのな

174 ：デフォルトの名無しさん：2010/11/11(木) 09:40:29

>>172
fast-forward mergeとそうでないmergeは、gitk --allでマージ前とマージ後を見ながら視覚的に確認するとわかりやすいよ

175 ：デフォルトの名無しさん：2010/11/11(木) 10:28:02

gitk --all やってみたらマージで混乱してた頃の
枝がはちゃめちゃに混線しててワロタ

176 ：デフォルトの名無しさん：2010/11/12(金) 11:44:13

書いてたらgit関係ないことに気づいたけどそのまま投稿するね

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

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

の3種類のテストが、少なくともpullリクエストでの説得に必要な気がするのです
うまいまとめ方ないでしょうか
訂正後のメソッドについてのテストだけだと、
「この動作は以前のコードではどうだったの？」という情報がなくて困りそうで

177 ：デフォルトの名無しさん：2010/11/12(金) 11:58:45

githubのpullリクエストの現在の挙動は、
ブランチに対してリクエストを出して、その後、そのブランチにコミットを追加すると、pullリクエストも伸びていく。
だから、pullリクエストはブランチ単位で分けた方が良いのでは？
マージするかどうかは、そのリクエスト先が判断すれば良い気がする。

178 ：デフォルトの名無しさん：2010/11/12(金) 12:07:11

ブランチ単位で説得して、ブランチの中のどのコミットを採用するかはまぁすたぁに任せる
だから普通に「○○を改善するブランチ」を作って、
訂正前コードに対するテストをコミットして(a)、
比較対照テストをコミットして(b)、
比較対照テストの部分を極力編集しないように訂正後のコードに対するテストをコミット(c)すればいいのでは
まぁすたぁはおそらく
「コミットすべてを見て納得して、(a)と(c)だけ受け入れ、適当にCHANGELOGを書く」
ということをするはず

…慣れてればな
…慣れてればね
慣れてないと「こんな大きいの無理です入りませんいやっやめてっ」とか返事が返ってくる

179 ：デフォルトの名無しさん：2010/11/12(金) 20:18:51

このへんの作法みたいなのの説明ってあんまりないよね
他者と関わりあっていかなければならないソフトウェアなのにさ

180 ：デフォルトの名無しさん：2010/11/14(日) 09:59:04

パッチはメールの本文にベタで置かないと読まないとかいうプロジェクト管理者もいるし、
いろいろなソフトをひとまとめにできるルールなんて作れない

181 ：デフォルトの名無しさん：2010/11/15(月) 10:33:41

gistが壊れてないか？
"New Gist"でPublic Gistを作ると
無関係のランダムな既存のgistからforkしたみたいになる
Privateだと起こらなかった。昨日から使い始めたんだか元々こうなの？

182 ：デフォルトの名無しさん：2010/11/15(月) 10:52:46

https://github.com/blog/744-today-s-outage

183 ：デフォルトの名無しさん：2010/11/15(月) 13:10:36

700000番から直ったみたい>gist

184 ：デフォルトの名無しさん：2010/11/15(月) 17:16:20

git cvsimportを始めてからもうすぐ20時間。
進行状況の表示もまったくないしいつになったら終わるんだこれは・・・

185 ：デフォルトの名無しさん：2010/11/15(月) 19:26:19

俺も以前cvsimportしたことあるけど、めっちゃ時間かかった上に
異常終了してたような気がするな。。。
ローカルにあるならまだしも、リモートではもうやりたくないと思った。

186 ：デフォルトの名無しさん：2010/11/16(火) 02:54:10

git svnも小さいプロジェクトなのに最初のcloneに小一日かかったわｗ

187 ：デフォルトの名無しさん：2010/11/16(火) 03:21:07

>>186
githubとかにもありそうな著名なプロジェクトなら、こういう手もある
git-svnを途中から始める - unpushの日記
http://d.hatena.ne.jp/unpush/20090826/1251281749

188 ：デフォルトの名無しさん：2010/11/17(水) 10:51:13

cherrypickのたびに1文字1文字コミット名を入力するのが大変なのですが，
簡単に入力できる仕組みはあるのでしょうか？
解説等を読んでも引数にSHAの頭数桁を指定しているだけで・・

189 ：デフォルトの名無しさん：2010/11/17(水) 11:44:01

>>188
ハッシュの意味をよーく考えよう

190 ：デフォルトの名無しさん：2010/11/17(水) 15:50:39

>>188
ターミナルからコピペするの楽だから大変と思ったことないな。
master~5みたいな記法使ったらどうだろ？

191 ：デフォルトの名無しさん：2010/11/17(水) 15:55:33

ああそうか、現在表示してるコミットのハッシュ値をマウス等でコピーできない環境なのか
それは使用環境が糞だというしかないな

192 ：デフォルトの名無しさん：2010/11/17(水) 16:37:39

マウスなくてもscreenでコピペしてる。
zshやbashならハッシュ一覧表示する補完関数書けばいけるかも。

193 ：デフォルトの名無しさん：2010/11/17(水) 17:09:01

最初の2文字ぐらい打てばほぼ一発補完できるeshellというかEmacs最強

194 ：デフォルトの名無しさん：2010/11/17(水) 18:37:54

環境はMacです．
Terminalなのでコピペできるんですが，
どうしてもUNIXの保管になれてると少しだけ入力してTabで保管してくれないのかなー
等と欲がでてしまって・・（マウスも使っていないのでタッチパッドだとやりづらいorz）

Git自体にそういった保管機能はないということですね・・
git log --oneline で地道に拾います・・

195 ：デフォルトの名無しさん：2010/11/17(水) 20:17:47

>>194
マウス使わないなら尚更screenがいいよ

196 ：デフォルトの名無しさん：2010/11/18(木) 03:08:53

てかSHA1を直打ちしなくていいように refs/heads があるんだと思うんだが、、、

197 ：デフォルトの名無しさん：2010/11/18(木) 06:20:40

>>196
こんなのあったんだ。

これってローカルのブランチ名と違うの？
ローカルのブランチ名に近い範囲だったら >>190の記法でいけるんじゃないの

198 ：デフォルトの名無しさん：2010/11/18(木) 08:00:45

>>197
ローカルブランチと同じだよ。
refs/heads/～とかrefs/remotes/～とかはそこまでを省略して指定することができる。
ちなみに.git/HOGEHOGEとかを勝手に作ってもgit log HOGEHOGEとか出来ちゃう。

199 ：デフォルトの名無しさん：2010/11/18(木) 11:08:08

へぇー、ORIG_HEADって定数が使えるのも .git/ORIG_HEAD の中を見てたってことなのか。

200 ：デフォルトの名無しさん：2010/11/19(金) 11:17:35

ということは.gitをgitで管理すればブランチの変異もバージョン管理できるわけか

201 ：デフォルトの名無しさん：2010/11/19(金) 11:23:35

>>179
githubについてはドキュメント足りないよね
pullリクエストを送るボタンの押し方なんて本気でどうでもいい

pullリクエストとして送る予定のコミットのいい書き方とか
pullリクエストの受け入れ方とか吟味の仕方とか説明がない

202 ：デフォルトの名無しさん：2010/11/22(月) 02:59:59

>>194
一意に決まる場合はハッシュの頭数文字だけの入力で適切に処理される。

203 ：デフォルトの名無しさん：2010/11/22(月) 03:19:55

今試してみたら、最低でも４文字は必要ぽい

204 ：デフォルトの名無しさん：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したもののみ的確に取り消すにはどうしたらよいでしょうか？

205 ：デフォルトの名無しさん：2010/11/27(土) 01:11:11

git reset head で、いいんじゃないかな

206 ：デフォルトの名無しさん：2010/11/27(土) 01:25:12

>>205
あれ？それでいいんだ
いけました

ありがとうございました！

207 ：デフォルトの名無しさん：2010/11/27(土) 13:17:58

複数のサブプロジェクトをひとつのリポジトリで管理するときの指針やコツみたいなのがあったら教えてください。

208 ：デフォルトの名無しさん：2010/11/27(土) 13:35:42

>>207
gitosis

209 ：デフォルトの名無しさん：2010/11/27(土) 15:06:43

>>208
そういう意味じゃないんじゃない？
submodule とか？　でもあんま使い勝手良くないんだよねぇ。

210 ：デフォルトの名無しさん：2010/11/29(月) 02:29:52

Gitならこの人に聞け！
というぐらいのGit使いが身近にいればな・・・
名古屋近辺にいないかな？

211 ：デフォルトの名無しさん：2010/11/29(月) 10:04:51

>>210
ttp://atnd.org/events/7556
のような集まりに参加すればいいんじゃないか。
ひとまず git 名古屋でググれ。

212 ：デフォルトの名無しさん：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にプッシュすると怒られてしまうという状態です

もっと上手な運用方法はないでしょうか・・

213 ：デフォルトの名無しさん：2010/11/29(月) 12:47:15

リモートのリポジトリって1個じゃだめなの？

214 ：デフォルトの名無しさん：2010/11/29(月) 13:11:34

＞RepoBにプッシュすると怒られてしまう

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

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

もしかしてresetした？それなら怒られて当然だ
普通に1つの共用リポジトリで
masterとstableブランチ作って運用するのじゃ駄目なの？

215 ：デフォルトの名無しさん：2010/11/29(月) 14:20:47

RepoBをなぜ使用しているかというと
開発に参加している各人がRepoBを持っていたほうが
お互いの修正がバッティングしにくいと考えたためです

RepoAに各人のブランチを作る方法も考えたのですが
開発に参加する人数が増えるとそのたびにブランチを切らないといけないのかなーと・・
どのみち各人のRepoBを作成しているのでそのほうがめんどくさいかもしれない・・ですね・・・

216 ：デフォルトの名無しさん：2010/11/29(月) 14:29:14

開発者各自はどうせ自前の作業用リポジトリを持つんだろうから、
・各自そこから中央にpush
・メンテナが各自からpull
のどっちかをやって、その都度当事者が責任を持ってコンフリクトを解消する。

お互いの修正がバッティングするのは分散して作業していれば必ず起こりうることで、
どこかでそれを解消したらそれ（マージされた状態）を保持しつづけるようにする
姿勢が必要。rebaseやcherry-pickしたら、された側のブランチは捨てるつもりで
やる必要がある。

217 ：デフォルトの名無しさん：2010/11/29(月) 22:37:21

>>215
個人用のリポジトリRepoBを外にも持つ理由がわからない。
冗長性を保つためだけの存在なら、ローカルから直接本番のリポジトリRepoAにプッシュせず、RepoBでブランチ切ってmasterへのマージ時にRepoAへプッシュするようHookさせたらいいんじゃないか？

218 ：デフォルトの名無しさん：2010/11/30(火) 03:28:14

>>210
とりあえず@bleisさんという人が詳しいみたいです。
どんな人か知りませんが。

219 ：デフォルトの名無しさん：2010/11/30(火) 17:53:39

一月前のエントリだが。
http://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html

220 ：デフォルトの名無しさん：2010/12/01(水) 08:41:10

マスタがsvnだとどうしてもrebase主義にならざるおえない。…追えない!?

221 ：デフォルトの名無しさん：2010/12/01(水) 08:50:24

はいはいワロスワロス

222 ：デフォルトの名無しさん：2010/12/01(水) 16:16:08

>>220
ﾅｶｰﾏ
git svn使うときはrebaseしまくりだわ

でも最近面倒なのでsvnにあるまじきリモートブランチ切りまくり

223 ：デフォルトの名無しさん：2010/12/01(水) 17:02:16

svnの人が居ると最終的にsvnにrebaseしないといけないのって泣けてくるよね。
svn側でブランチとか作ってもけっきょくただのコピーだし、gitから見れば別モノなわけで。
svnのDBにGit互換の世界が作れればいいんだけどねぇ。propsとかでどうにかならないかな。

224 ：デフォルトの名無しさん：2010/12/01(水) 22:46:16

無理にgit-svnで連携させようと思うのがいけないのだと悟った
.svnと.gitが共存するスペースを作れば種々の問題が解決した

225 ：デフォルトの名無しさん：2010/12/01(水) 22:58:09

それって削除ファイルがあったときにめんどくね？

226 ：デフォルトの名無しさん：2010/12/01(水) 23:01:32

コンフリクトした時も痛いことになりそうだ

227 ：デフォルトの名無しさん：2010/12/01(水) 23:34:57

svnからupdateする時はその都度branchを切るな
大した手間じゃないし

228 ：デフォルトの名無しさん：2010/12/02(木) 00:02:45

Macのデザイナーさんがよろこびそうなgitクライアントきてた
Tower - The most powerful Git client for Mac
http://www.git-tower.com/

229 ：デフォルトの名無しさん：2010/12/02(木) 00:25:06

>>228
やたらオサレだな。gitもマカーにかかればこうなるのかｗ

230 ：デフォルトの名無しさん：2010/12/02(木) 00:52:12

まだ使ってないから見た目でしか判断できないけどこりゃ…すごい…
毎回思うんだがgoogleの機能紹介アニメ作る人とか、レタッチツールやDAWのデベロッパには劣等感を感じてしまう。
飛車と角が合体したような連中ってのはいるもんなんだな。

231 ：デフォルトの名無しさん：2010/12/02(木) 01:03:46

こりゃいいなｗ

232 ：デフォルトの名無しさん：2010/12/02(木) 02:33:05

>>228
http://www.git-tower.com/img/screenshots/history_recent_big.jpg
うける

233 ：デフォルトの名無しさん：2010/12/02(木) 11:02:16

git mergetoolでP4Merge使ってるんだけどマージした後にgit statusすると
modifiedとなる場合とならずにNot currently on branchとだけ表示されてcontinueできない

234 ：デフォルトの名無しさん：2010/12/02(木) 23:30:20

>>230
Queen最強、と思ってたらKnightによくヤられる

235 ：デフォルトの名無しさん：2010/12/02(木) 23:34:35

紹介しておいてなんだけどMacじゃないから試せない・・・
試した人感想くれ

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

バージョン管理ソフトばかりの話しではないけど慣れないときに困るのが、なにすればいいねん？ってことだからな

236 ：デフォルトの名無しさん：2010/12/03(金) 00:53:57

GitX風だな。

237 ：デフォルトの名無しさん：2010/12/03(金) 01:22:15

これいいとおもったらコミットメッセージ日本語うてないなｗ

238 ：デフォルトの名無しさん：2010/12/03(金) 08:59:01

git-svnには完全には対応してないだと！？まーしょーがないか。
が、俺の感想。

239 ：デフォルトの名無しさん：2010/12/07(火) 09:11:31

>>4
これが日本語ファイル名を扱う唯一の手段？
みんな日本語ファイル名をどうやって扱ってるのかな？
コードは日本語ファイル名はないと思うけど、ドキュメントとか普通日本語でしょ。
ドキュメントはバージョン管理しないの？

240 ：デフォルトの名無しさん：2010/12/07(火) 09:27:13

追記
クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合

241 ：デフォルトの名無しさん：2010/12/07(火) 09:38:48

http://code.google.com/p/msysgit/issues/detail?id=80

242 ：デフォルトの名無しさん：2010/12/07(火) 09:42:31

ヨハネスやる気無さ杉だろ

243 ：デフォルトの名無しさん：2010/12/07(火) 11:20:19

>>239
cygwin使えば使えるらしい

244 ：デフォルトの名無しさん：2010/12/07(火) 12:11:54

SVNはちゃんと日本語ファイル名扱える(Linux/Windows間でも問題なし)のだけど
あれはどうやって解決してるんだろう

245 ：デフォルトの名無しさん：2010/12/07(火) 12:18:38

パスとログはUTF-8と決まっていてクライアントが自動的に変換してる

246 ：デフォルトの名無しさん：2010/12/07(火) 12:19:20

なんでGitだとそんな簡単なことが出来ないんだろう

247 ：デフォルトの名無しさん：2010/12/07(火) 12:20:37

まあ少なくとも
「UTF-8決め打ちでプログラムがファイルパスを自動変換する」
という台詞を見て何も感じない人向けのソフトウェアではない

248 ：デフォルトの名無しさん：2010/12/07(火) 12:34:12

>>245
違うよ。LANGで勝手に変換しちゃうんだよ。大きなお世話、勘違いだけど。
それが簡単だと思っているんなら、SubversionかBazaar使って満足していれば？

249 ：デフォルトの名無しさん：2010/12/07(火) 12:49:46

エンコーディングを自動判定してるなんて一言も言ってないのに
特定プラットフォーム限定のLANGとか持ち出して勘違いとか言われても

250 ：デフォルトの名無しさん：2010/12/07(火) 12:55:49

>>249
SubversionとBazaarがLANGで勝手に判定する勘違いアプリってこと

251 ：デフォルトの名無しさん：2010/12/07(火) 13:09:26

日本人でさえ混乱してるのに
ヨハネスが上手く作りこめる訳がないな

252 ：デフォルトの名無しさん：2010/12/07(火) 13:23:09

あらゆる意味で「日本人しかうまく作れない」と思う
おまえ日本人か、みたいな日本語べったりの外国人エンジニアなら可能かもしれんがまあ稀だな

俺らがやるヨーロッパ系言語のISO-8859-Xの扱いがへにょいのと同じ理屈

253 ：デフォルトの名無しさん：2010/12/07(火) 16:40:43

>>240
クライアントが「SJIS」のWindowsマシンは世界中どこにも存在しない。
CP932ならあるけど。

254 ：デフォルトの名無しさん：2010/12/07(火) 16:47:20

>>253
Microsoft コードページ 932（以下 CP932）は、マイクロソフト及び、MS-DOS の OEM ベンダが Shift JIS を独自に拡張した文字コードである。また同時に、CP932 は Shift_JIS の Windows アプリケーションにおける「実装」を指す用語であるとも言える。

シフト JIS
JIS X 0208 符号化文字集合を一定の規則に従ってシフトした文字符号化方式。具体的な内容は JIS X 0208:1997 に「シフト符号化表現」として記載がある。しかし、文脈によってはベンダ拡張されたコードセットを指している場合もある。
Shift_JIS
「シフトJIS」の IANA 登録名。

255 ：デフォルトの名無しさん：2010/12/07(火) 16:48:18

これも

SJIS
Shift_JIS の短縮形。Java では Shift_JIS と同義語。

256 ：デフォルトの名無しさん：2010/12/07(火) 16:50:36

だから何？

257 ：デフォルトの名無しさん：2010/12/07(火) 16:51:00

文盲乙

258 ：デフォルトの名無しさん：2010/12/07(火) 16:53:31

SJISじゃなくてCP932って言いたいだけちゃうんかと

259 ：デフォルトの名無しさん：2010/12/07(火) 16:54:43

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

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

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

260 ：デフォルトの名無しさん：2010/12/07(火) 16:58:04

>>240
> 追記
> クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合

Linuxが主環境のgitスレに書き込むのなら、きちんとお勉強してから書き込みましょう、ということ。

261 ：デフォルトの名無しさん：2010/12/07(火) 16:59:14

まず日本語の勉強したほうがいいんじゃないですか？

262 ：デフォルトの名無しさん：2010/12/07(火) 17:01:51

261 ：あぼーん [あぼーん] ：あぼーん

263 ：デフォルトの名無しさん：2010/12/07(火) 17:18:05

>>261
「クライアント」の意味が分からないので教えてください

264 ：デフォルトの名無しさん：2010/12/07(火) 17:26:47

それは　えいごです

265 ：デフォルトの名無しさん：2010/12/07(火) 19:22:55

> クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合
これがgit的に意味不明。
Linuxのリポジトリがbareなら日本語うんぬんは全く関係ない。

266 ：デフォルトの名無しさん：2010/12/07(火) 21:35:58

エスパーすれば、それをLinux上でもcloneしたりするんだろ
何の為かは知らないけど

267 ：デフォルトの名無しさん：2010/12/08(水) 01:21:31

CP932
SJIS
SHIFT_JIS
MBCS
Windows-31J
なんでこんなに色々あるの

268 ：デフォルトの名無しさん：2010/12/08(水) 01:58:15

>>267
すっげえ単純に言うと、
コンピュータのメモリが有限で、
なおかつ帳簿を印刷するための文字が互いに足りなかったから

一昔前のPHSとケータイの絵文字競争に近い
「○○が表示できる」という理由でPHSやケータイを切り替えたのと同じ事が、
昔はコンピュータシステムレベルで起きた

269 ：デフォルトの名無しさん：2010/12/08(水) 10:16:18

>>267
詳しいことはこのスレを参照ってことで、
http://hibari.2ch.net/test/read.cgi/tech/1274937437/
昔はSJISとCP932の違いは￥と～の半角だけ気をつけていれば良かったのだが、
Unicodeが絡むとカオスが増す

270 ：デフォルトの名無しさん：2010/12/08(水) 10:48:05

>>239
cygwinのgitでUTF-8で使えば大体いける。
少なくともUTF-8のLinuxとWindowsの間では自分の使っている範囲ではいけてる。

Mac OSXはシラネ。
よく比較対象に上がるけど、Mac OSXとLinux、Windows間はSubversionやBazaarでも大丈夫なのかよ

271 ：デフォルトの名無しさん：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にしても同様でした。

272 ：271：2010/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 のような簡単にできる機能はいかないようですね

273 ：デフォルトの名無しさん：2010/12/08(水) 20:08:25

merge がconflictして mergeが面倒なだけなら、そのCRLFのリポジトリのファイルを
dos2unixなりで一括変換してコミットしてからmergeすればいいのでは。
blame の情報はなくなちゃうけど。

一つ目のリンク先も同じこと書いてた。autocrlfをセットして全部 touch してcommitしたらどうかって。

274 ：デフォルトの名無しさん：2010/12/08(水) 21:22:30

>>270
> Mac OSXはシラネ。
> よく比較対象に上がるけど、Mac OSXとLinux、Windows間はSubversionやBazaarでも大丈夫なのかよ
大丈夫じゃないよ。SubversionやBazaarは、ファイル名にUnicodeを使っていれば大丈夫だと思っている情弱向け

275 ：デフォルトの名無しさん：2010/12/08(水) 22:58:53

それでもgitよりsvn,bzrがマシなのに変わりは……

276 ：デフォルトの名無しさん：2010/12/09(木) 16:39:28

git reset --hard
で消した操作って元に戻せますか？

277 ：デフォルトの名無しさん：2010/12/09(木) 19:53:11

>>276
コミットしてなくてもgit add済みだったならgit lost-found で捜せば見つかるかも知れない

278 ：デフォルトの名無しさん：2010/12/10(金) 09:16:16

git reflog -5
で確認して
git reset --hard HEAD@{1}
みたいなので戻れるんじゃね？

279 ：デフォルトの名無しさん：2010/12/10(金) 11:14:04

~/src
をgitで管理

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

なんてことできますか？

280 ：デフォルトの名無しさん：2010/12/10(金) 11:19:29

>>279
Pro Git - Pro Git 6.6 Git のさまざまなツールサブモジュール
http://progit.org/book/ja/ch6-6.html

281 ：デフォルトの名無しさん：2010/12/10(金) 11:23:14

あるディレクトリ以下の
*.c
*.cpp
*.h
*.cxx
*.pl
などの添え字のファイルだけgit add する方法ないのでしょうか？
findコマンドでみつけたものをパイプでgitに渡せばいいのでしょうか？

282 ：デフォルトの名無しさん：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

283 ：デフォルトの名無しさん：2010/12/11(土) 11:27:13

Gitで特定のファイルのみ管理したいときに、
.gitignoreで*.*で一度すべてを対象外にした上で、!.cや!.hとかで特定のファイルのみ管理対象にする。。。
みたいなことをしたら邪道といわれましたが、やはり管理したくないファイルを指定したほうがいいのでしょうか？

284 ：デフォルトの名無しさん：2010/12/11(土) 11:29:48

れっつごーまいうぇい！

285 ：デフォルトの名無しさん：2010/12/11(土) 11:58:22

addし忘れ多発しそう

286 ：デフォルトの名無しさん：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するとき不便

なんとかならないもの？

287 ：デフォルトの名無しさん：2010/12/12(日) 12:10:47

>>286
cloneを三回

288 ：デフォルトの名無しさん：2010/12/13(月) 06:01:42

ssh 経由で使うとsubmoduleがうまくpullできない
nfsでマウントし合わないとだめっぽい

289 ：デフォルトの名無しさん：2010/12/13(月) 10:06:42

git svn dcommit
で競合がおきます
リモートの状態を手元の状態に強制的にあわせるコマンドはないのでしょうか

290 ：デフォルトの名無しさん：2010/12/13(月) 18:56:01

>>289
git svn dcommitする前にgit svn rebaseするべき

291 ：デフォルトの名無しさん：2010/12/14(火) 00:01:59

git svn rebaseって使っても大丈夫なのかな・・・と思うので

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

という風にしてる

292 ：デフォルトの名無しさん：2010/12/14(火) 00:24:54

くろうしてるなー(ぼうよみ

293 ：デフォルトの名無しさん：2010/12/14(火) 07:12:04

git svn rebaseって要はsvn updateでしょ?
なにが心配なんだ…?

294 ：デフォルトの名無しさん：2010/12/14(火) 10:17:48

もうperforceにするわ

295 ：デフォルトの名無しさん：2010/12/14(火) 20:19:44

gitで共同開発する場合、
git --bare initして共有リポジトリを作るのが通常だと思います。
しかし共有レポジトリのコミットは弄れないし、共有リポジトリから他へpushすることも出来ません。

mercurialのように双方向にpush出来るような仕組みはgitには無いのでしょうか？
mercurialの場合、全てのリポジトリが同等で、どのリポジトリからどのリポジトリにpushするのも自由です。
こういう管理に慣れているとgitの共有リポジトリがとても融通の利かないものに感じてしまいます。

296 ：デフォルトの名無しさん：2010/12/14(火) 21:05:28

bare やめて detached commit をチェックアウトしておけばドッペルゲンガー
じゃなかったグレムリンに遭わないよ。

お互いが ip reachable だったら双方向 push/pull はできるはずだけど?

297 ：デフォルトの名無しさん：2010/12/14(火) 21:17:14

>>295
そもそもgitも特定の共有リポジトリを作ることの方が邪道。

298 ：295：2010/12/14(火) 22:07:53

>>296
>>297
ありがとうございます。

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

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

う～む、単純に自分の勉強不足のようです。
もっと勉強してみます。
参考になりました。ありがとうございました。

299 ：デフォルトの名無しさん：2010/12/14(火) 22:18:57

bareの話題ついでに聞きたいんだけど、
bareにする利点ってある？

プロジェクト管理のRedmineがbare要求するんで、.git指定したらそのまま通ったので面倒なのでそのまま使っちゃてるけど

300 ：デフォルトの名無しさん：2010/12/14(火) 23:15:39

>>299
push先が変なのをチェックアウトしてたりdirtyなワーキングディレクトリになってると
pushが通らなくなることがあるけどbareだとその心配がない、とかかなあ。
公開用のリポジトリで、そこで作業することはないっていう保証とか約束みたいなもんだと思う。

301 ：デフォルトの名無しさん：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とか儲かってるらしいんだから支援してくれてもよさそうな気がするんだけどなぁ。

302 ：デフォルトの名無しさん：2010/12/18(土) 14:07:38

>>301
https://github.com/schacon/gitscm/commit/813b98fcccbdb5e72cb6d552ae995ef294be8234

303 ：デフォルトの名無しさん：2010/12/18(土) 14:09:28

git-scm.comってRailsだったんだ

304 ：デフォルトの名無しさん：2010/12/18(土) 16:25:15

他のプロジェクトで開発されているソースを取り込んで
自分のプログラムを管理する、つまり
http://progit.org/book/ja/ch6-6.html
みたいなことを行いたいと考えています。

上のURL先のように直接rackのリポジトリをsubmodule化すると
rackに対して自分用の改変が行えない(文中にある「公開サーバにプッシュ」が行えない)
と思うのですが、実際にはどのようにすべきなのでしょうか？

305 ：301：2010/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とか？

306 ：デフォルトの名無しさん：2010/12/18(土) 20:00:02

慣れてるなら SCM 的に使いやすいし、ページキャッシュをきちんと使うとかプ
リレンダするとかすれば充分軽いんだから、git + Rails でもいいじゃないで
すか。しかし、年間数百万ドルもかかるとは...
# Donations made will actually go to the Git project under the
# Software Freedom Conservancy.

307 ：デフォルトの名無しさん：2010/12/19(日) 03:03:01

railsが重いっていつの時代だ？

308 ：デフォルトの名無しさん：2010/12/19(日) 05:24:01

すげーメモリ食うよ

309 ：デフォルトの名無しさん：2010/12/19(日) 05:54:25

もともと静的ページいくつかで済んでたのをわざわざRails。
まあ、いい。それでやってける自信があったんだろう。
しかし案の定、リソースが足りね～つって「緊急の寄付のお願い、
さもなくば広告貼るか。Oracleは高く買うみたいｗ」って頭おかしいだろ。
これだからRails界隈の連中はクソだってんだよ。Githubも同様の奴原。

310 ：デフォルトの名無しさん：2010/12/19(日) 05:55:29

Railsは「重い」よ

そりゃRailsを*ユーザーたちが*重く感じないようにリソース大量にぶち込めば重くはないだろうけど
そうしなければならないということはそもそもひとつの処理が重いんだよ

311 ：デフォルトの名無しさん：2010/12/19(日) 14:54:02

>>309
# Donations made will actually go to the Git project under the
# Software Freedom Conservancy.

312 ：デフォルトの名無しさん：2010/12/19(日) 16:09:40

まったくだアセンブラで書いて速度と容量を最適化すべき

313 ：デフォルトの名無しさん：2010/12/19(日) 16:14:06

>>311
だから？

314 ：デフォルトの名無しさん：2010/12/19(日) 17:59:00

Rails(Ruby)が流行りだったんだよ、文句いうな
しっかし、まだPHPの方が速そうだよなぁ、PHP嫌いだけど

315 ：デフォルトの名無しさん：2010/12/19(日) 21:04:33

そこでJRuby

316 ：デフォルトの名無しさん：2010/12/19(日) 21:16:06

>>314
git-scm.com見てみろよ。PHPである必要すらないだろ。。。
チャリンコで済むようなところにわざわざレーシングカーみたいなの持ってきて
ガス代足りないからカンパしてくれって言ってるようなもん。
流行ってるからとかいう話じゃない。

317 ：デフォルトの名無しさん：2010/12/19(日) 21:48:06

経験上だけどpassenger使わなければRailsはそんな重くない。
passengerはメモリ馬鹿食いするし、あれで嫌になってる人が多いのだろう。

318 ：デフォルトの名無しさん：2010/12/19(日) 23:07:22

freetypeのgitリポジトリにつながらない　何で

319 ：304：2010/12/20(月) 01:03:40

>>305
ありがとうございます。
やっぱりリポジトリは2つ必要になるんですね…

320 ：デフォルトの名無しさん：2010/12/20(月) 02:52:16

>>316
いやいやいやいや、
寄付してくれれてのはクリスマス限定のジョークのつもりだったんだってば。
寄付先は自分じゃないし、こっそり This page is a parody. とか書いてあるぞ。

321 ：デフォルトの名無しさん：2010/12/20(月) 06:30:18

>>320
なるほど、最近のWikipediaの寄付アピールのパロディなのか。
だいたいまだクリスマスじゃないし、笑えないし、公開後すぐ隠したりでグダグダすぎる。
せめてエイプリルフールにしろっての。

322 ：デフォルトの名無しさん：2010/12/20(月) 08:34:28

>>319
submoduleを使う場合はリポジトリを入れ子にして使うことになるので
両方公開するとしたら別々になるね。

サブツリーマージって方法もあるけど、、、こっちも分かりにくいけど、
submoduleよりはマシのような気がしないでもないかなぁ。

323 ：デフォルトの名無しさん：2010/12/20(月) 13:08:21

騙された人は必死にならず「あー騙されたぜ、はっはっは」と言えるくらいの
ゆとりを持ちましょう

324 ：デフォルトの名無しさん：2010/12/20(月) 13:33:44

せやな

325 ：デフォルトの名無しさん：2010/12/20(月) 15:03:26

笑えないジョークだから半日で消したんだよ。
そうじゃなければクリスマスまでやるでしょ。

326 ：デフォルトの名無しさん：2010/12/20(月) 15:34:41

もう一度同じこと書いてやろうか？

327 ：デフォルトの名無しさん：2010/12/20(月) 15:39:27

せやなｗｗｗ
やっぱ味噌ラーメン以外考えられんわ、ってな訳で解散

328 ：デフォルトの名無しさん：2010/12/20(月) 16:08:04

同じこと書くのはやめろ。ちゃんと自分の意見を書いてみろ。

329 ：デフォルトの名無しさん：2010/12/20(月) 20:29:04

オレの意見:

ハートキャッチプリキュアが終わったら生きていけない

330 ：デフォルトの名無しさん：2010/12/21(火) 07:18:08

>>301
あなた本気で言っているなら相当頭悪いですよw

331 ：デフォルトの名無しさん：2010/12/21(火) 09:56:12

一番前まで戻るなよw

332 ：デフォルトの名無しさん：2010/12/21(火) 13:23:41

オレの意見:

インデックスは俺の嫁

333 ：デフォルトの名無しさん：2010/12/21(火) 17:03:00

自分のsrcディレクトリ　~/src　に、他人のコードが便利そうだから
pull してもってくると

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

~/src/some_projectにpullしたのを展開する方法ないのでしょうか

334 ：デフォルトの名無しさん：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

335 ：デフォルトの名無しさん：2010/12/24(金) 13:55:54

ごめんpullじゃなくてcloneだった

336 ：デフォルトの名無しさん：2010/12/27(月) 15:37:19

pullとfetchとcloneの違いはなんなんでしょうか

337 ：デフォルトの名無しさん：2010/12/27(月) 15:41:11

>>336
http://progit.org/book/ja/

338 ：デフォルトの名無しさん：2010/12/27(月) 22:17:46

漢は黙って git init -> git fetch

339 ：デフォルトの名無しさん：2010/12/29(水) 22:44:16

git svn cloneで途中のリビジョンから複製したら
共通祖先がなくてマージできない
＼(^o^)／ｵﾜﾀ

340 ：デフォルトの名無しさん：2010/12/29(水) 23:06:25

svnからcloneした履歴はマージしないほうがいいけどね

341 ：デフォルトの名無しさん：2010/12/29(水) 23:11:44

>>340
え？・・・ああ、svnリポジトリの方は大丈だ夫
読み取りだけでdcommitはしない（出来ない）から。

問題はpushしたgitリポジトリの方だ・・・
またリモートのリポジトリ、作りなおさなきゃ

342 ：デフォルトの名無しさん：2010/12/29(水) 23:19:48

>>341
よくわからないが、同じツリーのコミットを見つけてマージしちゃうってのはどう？
一度マージしちゃえば共通祖先が出来る。まあヘンテコな履歴になるけどね。

343 ：デフォルトの名無しさん：2010/12/29(水) 23:35:02

svnの安定版ブランチからgitのブランチを作って、
それをpushしてソースコードを共有していたんだけど

svnのtrunkからの変更を取り込みたくなって、(gitのブランチで)マージを実行したら
全てのファイルがConflictして、共通祖先が無いことに気づいた
>>342
安定版ブランチだけ孤立している状態なんだけど、解決方法あるのかな・・・

344 ：デフォルトの名無しさん：2010/12/30(木) 01:13:42

>>343
そういうことか。。。キツいね。
svnのほうはmerge-trackingでマージしてるんだろうね。

svnのほうで、安定版ブランチとtrunkの足並みが揃ってるところがあったら
Gitのほうでもそこからフォークしたことにしてやればけっこうコンフリクト減ると思うけど、
そうでなければ地道にcherry-pickして履歴作ってみたり、とかかなぁ。
git-svnがmerge-trackingをサポート、、、するわけないよなぁ。

345 ：デフォルトの名無しさん：2010/12/30(木) 15:35:59

ちょっと質問いいでしょうか

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

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

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

疑問点は、

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

346 ：デフォルトの名無しさん：2010/12/30(木) 15:37:35

途中で送信してしまった・・・・

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

こういう事情の時はこうしたほうがよいのでは？ということをお聞きしたいのです。

347 ：デフォルトの名無しさん：2010/12/31(金) 05:18:36

> バージョンアップの度にリリースされたファイルの変化に追従していくうちに、変化を追うのが面倒になってしまいました。

これがよくわからないけど、リリース時にgit tag v1.0.1とかタグ打っておけばgit diff v1.0.0..v1.0.1で差分は見れるけどそういうことじゃないくて？

348 ：デフォルトの名無しさん：2010/12/31(金) 08:13:03

変化を追わないのならただのバックアップだよな…？

349 ：デフォルトの名無しさん：2010/12/31(金) 08:34:05

>>345
> とある既存の(特に公開リポジトリはなしの)ソフトやソース

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

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

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

350 ：デフォルトの名無しさん：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に取り込めばいいわけですし

人によってはログや履歴を捨てることを躊躇しない人も今までいました。
しかし個人的な感覚としてそれらはちょっと気持ち悪かったのでシステムで解決できるもっといい方法がないかと思いまして

351 ：デフォルトの名無しさん：2011/01/02(日) 17:06:11

git 自体のバージョンが違う、複数のマシンで
共同開発すると不都合ありますよね？

やはりコミットする人全員のバージョンは揃えておくものなのでしょうか？

352 ：デフォルトの名無しさん：2011/01/02(日) 17:55:08

バージョン違うことによる不都合って「git log --onelineで見てみて」「エラー出ました！」
とかいう人間同士のコミュニケーション部分くらいしか思いつかない

353 ：デフォルトの名無しさん：2011/01/02(日) 23:31:13

git rebase -i では操作対象コミットの中で最古のものより1つ古いコミットを
指定する必要があると認識しているのだけど、そうすると、最も古い(git init
直後の）コミットと最近のコミットをsquashでまとめることは不可能?
現在のコミット総数は10未満。

354 ：デフォルトの名無しさん：2011/01/03(月) 00:52:30

root commitに触手を伸ばそうとしている勇者であることは理解できた。

355 ：デフォルトの名無しさん：2011/01/03(月) 04:49:26

rm -rf .git/; git init; git add .; git commit -m "first commit";

356 ：デフォルトの名無しさん：2011/01/03(月) 06:50:49

>>355
最後の手段w

357 ：デフォルトの名無しさん：2011/01/03(月) 23:24:02

>>354
root commitっていうんだ調べてみます

>>355-356
やってみます！ありが

358 ：デフォルトの名無しさん：2011/01/03(月) 23:38:09

gitってcloneするときにリモートリポジトリもやっぱり全部もってきてる？
git branch -aでリモートブランチにもその場でcheckoutできるようだけど

それにしては速くてびっくりした

359 ：デフォルトの名無しさん：2011/01/04(火) 00:32:50

$ git rebase -i 最古のコミット
最古のコミットに混ぜたいコミットを一番上に移動して、push→editに変更
$ git reset --soft HEAD^
$ git commit --amend
$ git rebase --continue
でなんとなく望みの状態になったような気がします。

360 ：デフォルトの名無しさん：2011/01/04(火) 01:18:15

TortoiseGit の日本語化ってできないの

361 ：デフォルトの名無しさん：2011/01/10(月) 00:08:38

git svnで、ブランチとして扱うディレクトリって
「特定のフォルダの下のディレクトリ全て」ではなくて、
「特定の名前のディレクトリ」のように指定できる？

362 ：361：2011/01/11(火) 01:28:21

こんなふうにすれば、出来るみたい
"branches/*"の最後の*を消したら
One '*' is needed in glob: 'branches/hoge'
のように出たので、このメッセージでググッたら、偶然方法を発見した。

[svn-remote "svn"]
branches = branches/{hoge}:refs/remotes/*

363 ：デフォルトの名無しさん：2011/01/15(土) 14:21:46

>>360
1.3.2.0向けのはあるけど、開発止まってる
だから自分で言語パックを作ろうとしたのだけれども・・・
入れてみてもコンテキストメニュー以外が全て英語のままだ、なんでだろう

364 ：デフォルトの名無しさん：2011/01/17(月) 21:44:19

cvsのexportみたいなことって、
gitではどうやればいいですか？

365 ：デフォルトの名無しさん：2011/01/17(月) 22:17:06

管理情報なしの状態が欲しいならcloneから.gitまるごと消すだけ。
アーカイブを作りたいならgit archive

366 ：デフォルトの名無しさん：2011/01/18(火) 07:29:29

しかしコミット中に今はなきラージオブジェクトがある場合なんか、
cloneは大げさな気はする。というかよくそのcloneで固まる

367 ：デフォルトの名無しさん：2011/01/18(火) 08:46:33

git archiveはデフォルトでtarアーカイブを標準出力に吐き出すので、
cloneするよりパイプで (cd 目的地 && tar xf -) がいいかな。

368 ：デフォルトの名無しさん：2011/01/18(火) 22:33:17

上流が git-svn rebase (ただしリードオンリー)してて
各個人が git-svn dcommit したい場合の
具体的なワークフローが知りたい

いや教えてください

369 ：デフォルトの名無しさん：2011/01/18(火) 23:01:28

直接dcommitするなら、上流はsvnってことになるんじゃない？

370 ：デフォルトの名無しさん：2011/01/20(木) 09:22:22

>>350
cd new_my_repo
git remote add my_repo ../my_repo
git pull my_repo master

371 ：デフォルトの名無しさん：2011/01/23(日) 23:57:38

日本語で書いたログメッセージはちゃんとUTF-8で保存されてんの？

372 ：デフォルトの名無しさん：2011/01/24(月) 01:07:10

UTF-8で書けばな

373 ：デフォルトの名無しさん：2011/01/25(火) 01:00:08

あるブランチのコミットが別のブランチに全部取り込まれてるか簡単に確認する方法
教えてください

374 ：デフォルトの名無しさん：2011/01/25(火) 01:36:19

>>373
実際にマージしてみる。

375 ：デフォルトの名無しさん：2011/01/25(火) 13:18:17

>>373
git cherry A B
何も出てこなければBのコミットは全てAに入っている

376 ：デフォルトの名無しさん：2011/01/25(火) 22:55:07

>>374
マージされちゃいます＞＜；

>>375
ありがとうございます

377 ：デフォルトの名無しさん：2011/01/26(水) 01:48:53

マージしてもプッシュしなきゃよか。
リセット操作に抵抗あるならディレクトリごと別にコピーして試すがよか。

378 ：デフォルトの名無しさん：2011/01/26(水) 12:19:38

ファイルシステムとしての Git
http://d.hatena.ne.jp/propella/20110105/p1

379 ：デフォルトの名無しさん：2011/01/31(月) 18:06:23

1.7.4 released
ttp://article.gmane.org/gmane.comp.version-control.git/165718

380 ：デフォルトの名無しさん：2011/02/01(火) 14:47:45

masterがメインで走ってて、安定版をFastForwardでstableブランチにmergeしていってるよくある
リポジトリで、コミットAとCとFとがstableだったってstableの履歴のようなもの知りたいのですが、
何か手はないでしょうか？

381 ：デフォルトの名無しさん：2011/02/01(火) 17:06:21

git tag

382 ：380：2011/02/01(火) 17:27:50

それが tag のふられてない既存リポジトリなんですよ
つまりは手はなしってことですか

383 ：デフォルトの名無しさん：2011/02/01(火) 21:20:01

>>380
リアルタイムで追いかけて merge とか cherry-pick があったときに tag とか branch でくさび入れるがよろし!

384 ：デフォルトの名無しさん：2011/02/02(水) 00:02:23

tagって任意のhashにつけられるんじゃなかったっけ？

385 ：デフォルトの名無しさん：2011/02/02(水) 00:45:24

いつの間にかTortoiseGitが1.6.3.0にバージョンアップしてた

386 ：380：2011/02/02(水) 09:36:52

具体的にいうとx264のgitリポジトリなんだけどね
masterがどんどん走ってて、ここまでならstable!ってポリシーで行ってるの
はいいけど、１個前２個前のstableをcoしたい。ってのができなくて。
committer が >>383 の言うように "stable:r1875" みたいなtag打ってくれりゃいいんですけどね(´・ω・｀)
どうにもリアルタイムで追いかけてstableなポイントをメモしとかないとダメっぽいですね。
ありがとうございました。

387 ：デフォルトの名無しさん：2011/02/02(水) 19:44:38

git-svn で元リポジトリの構造が svn/trunk だったのから svn/proj/trunk みたいに
階層構造が変化した場合って git svn clone からやり直さなきゃダメ？

388 ：デフォルトの名無しさん：2011/02/02(水) 23:14:08

同じような状況で、.git/config だけ書き換えたら大丈夫だろうと思って
やったらダメだったことはある。

389 ：デフォルトの名無しさん：2011/02/03(木) 00:08:21

>>388 ﾅｶｰﾏ
なんか git svn relocate svn/trunk svn/proj/trunk みたいなのがあるんじゃないかと
思って調べても全然見つからないのよね。

390 ：デフォルトの名無しさん：2011/02/03(木) 00:29:59

それは git svn が svn switch --relocate をちゃんとしてくれないってこと？

391 ：デフォルトの名無しさん：2011/02/03(木) 01:41:56

git svn はclone元のsvnリポジトリの構造変化に追従してくれないんじゃない？ってこと。

392 ：デフォルトの名無しさん：2011/02/03(木) 01:58:57

いや、svnだってcheckout元のsvnリポジトリの構造変化には追従しないよ。
だから svn switch --relocate があるでしょ？
git svn は git svn switch --relocate を受け付けてくれないの？と聞いた
つもりだったんだけど？

393 ：デフォルトの名無しさん：2011/02/03(木) 11:07:40

>>392
試してみた。
>いや、svnだってcheckout元のsvnリポジトリの構造変化には追従しないよ。
あらホント。move を追跡してくれるものと思い込んでた。

で、git svn switch は git svn switch 自体が無いみたいですね。

394 ：デフォルトの名無しさん：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 が変化検出できないっぽい。

395 ：デフォルトの名無しさん：2011/02/03(木) 16:01:23

なんというバッドノウハウ
でもメモっとこう

396 ：デフォルトの名無しさん：2011/02/03(木) 17:38:43

そのうち git svn switch が実装されると信じて

397 ：デフォルトの名無しさん：2011/02/09(水) 18:55:07

TortoiseGitでプロジェクトの管理を行っていますが、
一度clone等でデータを取ってくると、フォルダを消そうとしても
消せなくなってしまいます。
調べてみるとTGitCache.exeというプログラムがプロジェクトの
フォルダを使用しているようです。なのでフォルダを消す時は
TGitCache.exeを終了させてから削除しています。

他のユーザーの方も同じ現象が起きるなどしていませんか？

398 ：デフォルトの名無しさん：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 になっているため、
＃こんなことで悩んでおります。

399 ：デフォルトの名無しさん：2011/02/09(水) 19:22:43

aliasで!shとか使えば？

400 ：デフォルトの名無しさん：2011/02/09(水) 20:45:18

>>398
その設定だと、コミットログが化け化けで入っていないか？
コンソールでしか作業をしないのなら、ロケールと端末をEUC-JPに変えるという発想は？
LANGだけでロケール変わらないか？

401 ：デフォルトの名無しさん：2011/02/09(水) 21:12:26

漏れならソースコードをUTF-8にするの一択

402 ：398：2011/02/09(水) 21:38:07

>>399
私にレスをくださったんでしょうか?
そうだとしたら申し訳ないんですが、
おっしゃってる意味が理解できませんでしたorz

>>400
> その設定だと、コミットログが化け化けで入っていないか？

設定をしないと、git logしたときに化けていました。

ログ入力に使っているエディタ(emacs)のデフォルトエンコーディングはeuc-jpにしてあるので、
コミットログ自体はeuc-jpでgitのリポジトリに格納されるのかな?と思っています。

・・・が、
そうだとすると、
　　logoutputencodingをutf-8に設定する
　　=> gitがコミットログをutf-8に変換してから出力してくれている
　　=> だから文字化けせずに読めた
・・・ということになってしまいますね。
別にlogoutputencodingの設定通りに変換してから出力してくれるわけではないですよね?

> コンソールでしか作業をしないのなら、ロケールと端末をEUC-JPに変えるという発想は？
> LANGだけでロケール変わらないか？

以前は.bashrcにexport LANG=ja_JP.EUC-JPなどと書いていたはずなんですが、
どういうわけだったか忘れましたが、(←アホ)
何か理由があってlocaleはシステムデフォルトにしたという経緯があります。

自宅の環境ではないので、明日、もういちどそのあたりを確認してみようと思います。

403 ：デフォルトの名無しさん：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で正解のようだ。

404 ：398：2011/02/09(水) 22:00:16

>>401
> 漏れならソースコードをUTF-8にするの一択

自宅ではそうします！

405 ：デフォルトの名無しさん：2011/02/09(水) 22:00:44

>>402
>>399は
https://git.wiki.kernel.org/index.php/Aliases
でnkf入りのdiffコマンドを作る

406 ：398：2011/02/09(水) 22:04:50

>>403
読んでみます！
ありがとうございます。

>>405
いろいろ情報ありがとうございます。
そちらも読ませていただきます！

407 ：デフォルトの名無しさん：2011/02/09(水) 22:11:46

重要な１行があった
> If you do not have this configuration variable, the value of i18n.commitencoding is used instead.
logoutputencodingが設定していないとcommitencodingが使われるってことか。

408 ：デフォルトの名無しさん：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等もフィルタすると幸せになれるかもしれない

409 ：398：2011/02/10(木) 23:32:06

>>398ですが、
アドバイスもらったこと中心に
今日3時間くらいかけて色々見てきました。

情報をいただいたおかげで、
なんか進展した気がします。
ありがとうございました。

###シェルで「export LANG=ja_JP.eucJP」しておく方法###
システムの標準がUTF-8なせいか、
基本的なコマンド類が日本語としてUTF-8のメッセージしか吐かないため、
「export LANG=ja_JP.eucJP」はしないようにしていたんでした。

また、LANGをja_JP.eucJPにしてみても、
肝心のgitの出力は化けたままでした。

###gitattributesのdiff.textconvを使う方法###
gitのv1.7.4で、
git diffの出力について、
この方法でうまく行きました。
ただし、git add -pのときの出力は化けたままでした。

textconvがどのバージョンから使えるようになったの理解しておらず、
いちばんハマりました。
v1.6.0で試す→textconvをまったく介さない模様
v1.6.5で試す→textconvに指定したコマンドにオプションを直接指定できない(nkf -wの「-w」のようなオプションを指定できない)
v1.7.4で試す→うまくいく

410 ：398：2011/02/10(木) 23:41:08

あとは、git add -pしたときに、
ソースコードの日本語コメント部分が化ける問題が残っている
・・・のは残っているんですが、
なぜかWindowsXPからputtyを端末にして接続すると化けませんでした。

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

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

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

　○: 文字化けしない　×: 文字化けする

411 ：デフォルトの名無しさん：2011/02/11(金) 00:01:52

windowsすげー

412 ：デフォルトの名無しさん：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"

413 ：デフォルトの名無しさん：2011/02/14(月) 17:07:01

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

414 ：デフォルトの名無しさん：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/

415 ：デフォルトの名無しさん：2011/02/14(月) 20:23:08

どうして、京都大学霊長類研究所は、アイちゃんの、
スレ乱立を見過ごしてるの？

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

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

糞スレをあちこちにポンポン乱立されちゃ迷惑なんだよ。
ったく、京都大学霊長類研究所は能無しの集まりかよ！

416 ：デフォルトの名無しさん：2011/02/14(月) 20:50:31

これが、コピペにマジレスの実物か

417 ：デフォルトの名無しさん：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=
まさにコピペにマジレス

418 ：デフォルトの名無しさん：2011/02/14(月) 23:25:17

Bazaarのドキュメント - 変化に強いバージョン管理システム
http://doc.bazaar.canonical.com/ja/

419 ：デフォルトの名無しさん：2011/02/14(月) 23:42:28

何でbzr貼るん？

420 ：デフォルトの名無しさん：2011/02/15(火) 00:08:58

http://hibari.2ch.net/test/read.cgi/tech/1265951333/999

馬鹿が悪乗りしてるから

421 ：デフォルトの名無しさん：2011/02/15(火) 02:30:28

【bzr】Bazaarでバージョン管理 Rev 3
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

422 ：デフォルトの名無しさん：2011/02/16(水) 11:20:36

GitGitにしてやんよ！

423 ：デフォルトの名無しさん：2011/02/16(水) 11:47:47

GitGitにしてください
http://wiki.bazaar.canonical.com/BzrVsGit

424 ：デフォルトの名無しさん：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

425 ：デフォルトの名無しさん：2011/02/16(水) 11:51:02

うむ、InternalServerError出たからマジで驚いたｗ
リロードしたら直ったけど、This page is obsolete! じゃん！

426 ：デフォルトの名無しさん：2011/02/16(水) 12:53:39

>>424
> Gitユーザは、リベースの難しさや、多くのBazaarユーザのやり方に対する非難めいた態度にイライラするかもしれません。 Bazaarでは、コミットは「重たく」、ブランチもとても「重たい」ものです。

427 ：デフォルトの名無しさん：2011/02/16(水) 21:31:26

そこ翻訳ちょっとへんだよな

428 ：デフォルトの名無しさん：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.

429 ：デフォルトの名無しさん：2011/02/16(水) 22:14:04

> Gitユーザは、リベースの難しさ、そしてやり方についての多くのBazaarユーザのとても非難めいた態度に、
イライラするかもしれません。

430 ：デフォルトの名無しさん：2011/02/19(土) 13:11:26

GITはいつになったら日本語ファイル名に対応するんだ？

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

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

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

怖くて使えねーｗｗｗｗｗ

431 ：デフォルトの名無しさん：2011/02/19(土) 13:21:19

ユーザの多くがプログラマーなら、そんなもの必要だとは思ってない。

432 ：デフォルトの名無しさん：2011/02/19(土) 13:25:42

>>430
Mercurial追い出されて今度はこっちですか？
具体的にどこがどう対応していないのですか？

433 ：デフォルトの名無しさん：2011/02/19(土) 15:17:57

GITでは、WindowsとLinuxの相互運用で日本語ファイル名が文字化けする。

実用に使えない糞ソフト。

434 ：デフォルトの名無しさん：2011/02/19(土) 15:21:37

「文字化け」という言葉を使っている時点で馬鹿丸出し

435 ：デフォルトの名無しさん：2011/02/19(土) 15:24:44

「実用に使えない」とか日本語不自由な人間が日本語ファイル名なんか気にすんなよ

436 ：デフォルトの名無しさん：2011/02/19(土) 16:42:10

GitもTortoiseGitも使ってるけど
2010年代にもなってダメ字に引っかかる仕様なのはアホとしか言いようがないな
対応してくれた人もいるわけだし(古いバージョンしかないけどorz)さっさ取り込んでやれよ

437 ：デフォルトの名無しさん：2011/02/19(土) 16:44:00

機能面で反論できないところを見ると、やはりGITが糞ソフトであることは間違いないようだ。

438 ：デフォルトの名無しさん：2011/02/19(土) 16:44:00

Gitの時代になっても日本人は英語コミュニティに及び腰、だろ?

439 ：デフォルトの名無しさん：2011/02/19(土) 16:54:38

2010年代にもなってWindowsがCP932なのがアホ
CP65001になればみんなハッピー

440 ：デフォルトの名無しさん：2011/02/19(土) 16:57:45

TortoiseGitで日本語ファイル名を使う需要が本当にあるのか。
地雷があるのが分かっているのに。
でも、UTF-8の需要は海外の方が大きい気がする。

441 ：デフォルトの名無しさん：2011/02/19(土) 17:07:01

メジャーなOSで普通にファイル名に利用出来る文字で文字化けが起こるソフトが糞。

そんなソフト使いものにならない。

442 ：デフォルトの名無しさん：2011/02/19(土) 17:08:37

どんな文字でもどんな長さでもファイル名に使えると思ってる世代は幸せだね。
ファイル名なんてVCSの極々々々々々一部だよ。

443 ：デフォルトの名無しさん：2011/02/19(土) 17:17:18

git config --global core.quotepath false を知らないアホがいると聞いて

444 ：デフォルトの名無しさん：2011/02/19(土) 17:19:04

>>443
だめだよ、余計なこと教えちゃ

445 ：デフォルトの名無しさん：2011/02/19(土) 17:26:00

quotepathやログを含め、Gitの多言語対応はしっかりしている。

446 ：デフォルトの名無しさん：2011/02/19(土) 19:13:36

GITはクロスプラットフォームで文字化けが発生してしまうから使いものにならない。

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

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

どうせファイルとかも消えちゃうんだろ。

447 ：デフォルトの名無しさん：2011/02/19(土) 19:15:17

>>446
じゃあそれでいいです

はいほかの方どうぞ

448 ：デフォルトの名無しさん：2011/02/19(土) 19:19:05

うむ、>>446に賛同しておこう
では次の話題に

449 ：デフォルトの名無しさん：2011/02/19(土) 19:26:55

文字化けの話題はもう>>443で解決してる
次の話題どうぞ

450 ：デフォルトの名無しさん：2011/02/19(土) 19:28:41

>>449はクロスプラットフォームでの問題を理解出来ないバカ。

451 ：デフォルトの名無しさん：2011/02/19(土) 19:36:27

cygwinも使えない馬鹿がいると聞いて

452 ：デフォルトの名無しさん：2011/02/19(土) 19:38:53

cygwinを使わないと日本語環境でまともに利用できないバカなソフトがあると聞いて

453 ：デフォルトの名無しさん：2011/02/19(土) 19:40:10

UIがcygwin環境に縛られる時点で、Windowsソフトとして終わってる。

454 ：デフォルトの名無しさん：2011/02/19(土) 19:41:07

そもそもWindowsソフトじゃないし。

455 ：デフォルトの名無しさん：2011/02/19(土) 19:44:43.88

やっぱりGITはWindows未対応なんだ。

確かにあんなに文字化けが発生する状態でWindows対応だなんて恥ずかしくて言えないわな。

456 ：デフォルトの名無しさん：2011/02/19(土) 19:46:38.03

どっちかっつーといつまでもUTF8ロケール用意できないWindowsが終わってるのでは

WindowsがいつまでもCP932みたいなレガシーなコードページを使わせるとしても
せめてMSVCランタイムのC/C++ロケールでUTF-8をサポートできていれば
マシかもしれないが、それも無い
だからWindowsでは、OS内部ではUnicodeのくせに、それをprintf()などで
標準出力に出力することすらできない

457 ：デフォルトの名無しさん：2011/02/19(土) 19:48:50.21

Windows批判はスレ違いです。

458 ：デフォルトの名無しさん：2011/02/19(土) 19:50:47.29

え、Windows って GIT 未対応なの?

459 ：デフォルトの名無しさん：2011/02/19(土) 19:52:32.30

クスクス…いまどきGitが使えない環境なんて遅れてるｗ

460 ：デフォルトの名無しさん：2011/02/19(土) 19:54:36.33

　//／／／／／／,　''"　　ヽﾐ川川
　|//／／／／,　'"　　　　　　　',川川
　川/////,　'",,,,,,,,,,,,,,,,　　　　r''"',川||
　川f 川f´　　　　　　　　　　 ,ィ::ﾗ',川　　やだっ…私のバージョン管理システム、日本語ファイル名使えない…？
　川ﾍ　 |　　　弋て::>　　　　￣　',ﾘ
　川ﾍ.__　　　　　　　　　　ヽ　／７!　　（２９歳 Aさんの場合）
　　川川ﾍ　　　　 _,.　'-‐''"´y'　 //
　　川川ﾘﾍ　,　'´　　　__,,,／　 / /
　　川川川|/　　　'"´　　　,　'´ /||
　　川川川|　　　　　　　　　　 /川

461 ：デフォルトの名無しさん：2011/02/19(土) 19:57:12.19

えっ、日本語ってGitに対応してないのｗｗｗｗ

462 ：デフォルトの名無しさん：2011/02/19(土) 19:58:34.73

>>461
EUC-JPもUTF-8も対応しています。cygwinでも。

463 ：デフォルトの名無しさん：2011/02/19(土) 20:07:37.57

>>462
おちつけ

464 ：デフォルトの名無しさん：2011/02/19(土) 20:08:16.80

開発陣を無能だと思うんなら有能な君がパッチを送ればいいじゃないか

465 ：デフォルトの名無しさん：2011/02/19(土) 20:14:30.50

タグを見るんだ
http://repo.or.cz/w/git.git
あとは分かるな？

466 ：デフォルトの名無しさん：2011/02/19(土) 20:17:44.80

>>463
当然ISO-2022-JPも対応しています。cygwinは分からん。

467 ：デフォルトの名無しさん：2011/02/19(土) 20:22:21.82

Windowsで使えないなんて信じられないニダ！
我が国の母国語が化けるとかクソニダ！
早く使えるようにしろ！！！　謝罪しろ！　賠償しろ！！！

どっかの国の人みたいなこと言ってんなよ、、、

468 ：デフォルトの名無しさん：2011/02/19(土) 21:37:46.55

単にGITが日本では実用にならない糞ソフトってことだよ。謝罪も賠償も必要ない。

469 ：デフォルトの名無しさん：2011/02/19(土) 22:30:51.44

と言うことにしたいのですね？

470 ：デフォルトの名無しさん：2011/02/19(土) 22:34:27.75

>>468
GITとやらが糞ソフトならLINUXは何ソフト？

471 ：デフォルトの名無しさん：2011/02/19(土) 22:35:24.29

比較的有用なOS

472 ：デフォルトの名無しさん：2011/02/19(土) 23:51:22.82

git grep って
現在いるフォルダとサブフォルダを検索対象にするけど
トップディレクトリ(.gitのあるとこ)以下を検索したいときは
どうすれバインダー
おしえてケロリン

473 ：デフォルトの名無しさん：2011/02/20(日) 01:09:11.88

git help grep

--max-depth <depth>

474 ：デフォルトの名無しさん：2011/02/20(日) 12:38:06.45

>>471
それじゃWINDOWSは？

475 ：デフォルトの名無しさん：2011/02/20(日) 13:10:54.21

比較的有用なOS

476 ：デフォルトの名無しさん：2011/02/20(日) 18:06:55.87

比較対象は秘密だけどな

477 ：デフォルトの名無しさん：2011/02/20(日) 18:29:21.33

>>476
Minix

478 ：デフォルトの名無しさん：2011/02/20(日) 20:07:45.05

>>476
Winが公式に認める比較対象は、旧バージョンのWinのみ。

479 ：デフォルトの名無しさん：2011/02/21(月) 17:05:32.87

共有リポジトリサーバで、ブランチ毎に clone/push/pull するにはどうすればいいんですかね？
そもそも、ブランチ毎にリポジトリサーバ立てるもの？

480 ：デフォルトの名無しさん：2011/02/21(月) 22:12:01.03

んなこたーない。指定できるよ。

481 ：デフォルトの名無しさん：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

まちがってたらごめん。自分も勉強中なんだ。

482 ：デフォルトの名無しさん：2011/02/22(火) 09:28:51.24

ありがとうございます。
なるほど。
ということは、別ブランチにpushしたものをcloneすると、
そのブランチもついてくるって感じですかね。
とにもかくにも、上記試してみます。

483 ：デフォルトの名無しさん：2011/02/22(火) 10:46:46.76

自分も似たようなことしたくて調べてみたら
使いたいのはサブモジュールなんだな、とわかったんだけど、なにこの魔境… orz
サブモジュールの中に居るかどうかで、コマンド体系を切り替えないといけないのは
なんの苦行なんだろう。とても魅力的な機能なのになぁ。
どうしてこうなった…。

484 ：デフォルトの名無しさん：2011/02/22(火) 13:09:01.34

サブモジュールはどうしても必要に迫られない限り、やりたくないなぁ。
ありゃキツいよ…

485 ：デフォルトの名無しさん：2011/02/22(火) 22:02:51.69

サブモジュールがいやならrepoを使えばいいじゃない。

486 ：デフォルトの名無しさん：2011/02/22(火) 23:47:55.59

>>485
おー、これ良さそうだね！教えてくれてありがとう！

487 ：デフォルトの名無しさん：2011/02/23(水) 21:58:26.22

オブジェクトは共用(bareでも可)で、複数のディレクトリで各ブランチをチェックアウトしたままにしておきたいんだがどうすればいい?

単一のリポジトリにてcheckoutでブランチを切り替えると、autoconf絡みで怒涛のようにfull rebuild状態になっていやん。

488 ：デフォルトの名無しさん：2011/02/23(水) 22:49:06.02

>>487
オブジェクト共用って、ディスクスペースを節約したいってこと？
cloneのオプションでハードリンクにすることも出来るけど、そういうことではなく？

489 ：デフォルトの名無しさん：2011/02/23(水) 23:13:58.16

>>488
Unixだと問題ないのかな? win だと無理?
git gc のことを考えなければ、単純に git を騙して共用させられればいけるような気もするが…

490 ：デフォルトの名無しさん：2011/02/24(木) 07:49:44.01

git-new-workdir

491 ：デフォルトの名無しさん：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 は動作を停止しました
って出る。なんで？

492 ：デフォルトの名無しさん：2011/02/26(土) 15:34:40.78

質問させてください。

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

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

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

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

よろしくお願いします｡

493 ：492：2011/02/26(土) 15:38:21.40

俺様がよくやる方法みたいな情報も大歓迎です｡

よろしくお願いします｡

494 ：デフォルトの名無しさん：2011/02/26(土) 15:44:37.68

>>492
ほんの軽い差分ならstash、いくつかのコミットになるなら俺ブランチでrebase、
って感じかな。

495 ：デフォルトの名無しさん：2011/02/26(土) 15:59:29.46

>>494
早速のレスありがとうございます！

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

どんどん進化していくような俺コードだとstashは不適切という訳ですね｡
φ(..)メモメモ

496 ：デフォルトの名無しさん：2011/02/26(土) 22:26:22.55

>>495
どっかの公開repoに俺修正で追っかけてくのは、Git使うと基本作業みたいなものなので、
mergeして追随するパターン、rebaseするパターン、とりあえずstash、
それぞれじっくりやってみたらいいと思うよ。

497 ：デフォルトの名無しさん：2011/02/26(土) 23:35:24.82

>496
レスありがとうございます！

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

merge、rebase、stashそれぞれ使いどころがあるってことですね。
φ(..)メモメモ

498 ：デフォルトの名無しさん：2011/02/27(日) 01:49:19.63

>492
2以外はだいたい一緒
stashは使いどころをまだよく理解していないもんで

499 ：デフォルトの名無しさん：2011/02/27(日) 02:26:42.81

>>492
俺コードをguiltで管理する方法もある

500 ：デフォルトの名無しさん：2011/02/27(日) 12:49:05.29

>>498 >>499
レスありがとうございます！

> 2以外はだいたい一緒

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

> 俺コードをguiltで管理

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

ざっと調べてみましたが、stashと異なるのは､
・gitのコミットとして管理される
・適用したquiltを元に戻すのが簡単
といったところでしょうか｡

501 ：デフォルトの名無しさん：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

502 ：デフォルトの名無しさん：2011/03/06(日) 07:12:59.56

>>501
何かおかしいみたいだけど、どういう設定でgit-svn initしたのかな？

503 ：デフォルトの名無しさん：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

504 ：デフォルトの名無しさん：2011/03/07(月) 04:02:31.92

>>503
LinuxとOSXで試して分かった。
同じディレクトリに大文字、小文字だけ違うファイルがあるんだけど
OSXはそれを同じファイルとして扱うから先に作られたファイルが上書きされるんだ。

505 ：デフォルトの名無しさん：2011/03/07(月) 09:16:41.48

となると、OSX的にはcase sensitiveなディスクイメージを作って、それを
マウントして、その中で作業することになりそうだな。
起動ボリューム自体をcase sensitiveにすると、動かなくなる市販アプリが
あったりするのでお勧めしない。

506 ：デフォルトの名無しさん：2011/03/07(月) 10:35:15.55

>>504
俺もそれバグかと思った。checkoutでも怒られることあるよ

507 ：デフォルトの名無しさん：2011/03/07(月) 10:44:22.92

ところで大文字小文字の違いだけでファイルを分けるのはどうなんだろう
よくやることなの？
作法云々もあるけど非常に管理しにくくなると思うんだが

508 ：デフォルトの名無しさん：2011/03/07(月) 11:02:20.08

>>507
微妙な違いだと目視で間違えそうだし、HFSみたいなファイルシステムのことを考えるなら
あまりよくないだろうね。

509 ：デフォルトの名無しさん：2011/03/07(月) 11:15:23.38

カビの生えたソフトのtar玉(.tar.Zだったりする)の中に
makefileとMakefileが入っていて、脳裏でプツンという音が
聞こえた遠い日。

510 ：デフォルトの名無しさん：2011/03/07(月) 11:17:51.63

ああ
昔はよくあったな
同じファイルなのに
起動される名前が違うだけで
挙動が変わるのとか

511 ：デフォルトの名無しさん：2011/03/07(月) 11:39:42.49

呼ばれる名前で挙動が変わる？　Gitはそうだよｗ
シェルスクリプト以外はほぼ全部ハードリンクｗｗｗ

512 ：デフォルトの名無しさん：2011/03/07(月) 13:12:56.37

え・・・なんで一人でテンション上がってんのこの人

513 ：デフォルトの名無しさん：2011/03/07(月) 16:26:20.91

すまん、寝てないんだ

514 ：501：2011/03/07(月) 22:59:09.31

>>502
そのリビジョンでまだ存在しないブランチを指定してfetchすると、固まって進まなった事があったので、
ブランチの追加されるリビジョンでconfigを変えることを繰り返し、現在こんな感じです
[svn-remote "svn"]
url = https://irrlicht.svn.sourceforge.net/svnroot/irrlicht
fetch = trunk:refs/remotes/trunk
branches = branches/releases/*:refs/remotes/*
branches = branches/{SkinnedMesh}:refs/remotes/*
branches = branches/{ogl-es}:refs/remotes/*
branches = {vendor}:refs/remotes/vendor/*
tags = tags/*:refs/remotes/tags/*

515 ：デフォルトの名無しさん：2011/03/08(火) 01:24:12.96

OSはwindows7
管理するものはC++のソース、
利用人数は１人、
として使うバージョン管理システムで
Gitはオススメできますか？
もしオススメできないとしたら他にはどのような選択肢がありますか？

516 ：デフォルトの名無しさん：2011/03/08(火) 01:27:00.25

gitマジおぬぬめ

517 ：デフォルトの名無しさん：2011/03/08(火) 02:16:48.91

hgがいいんでね？

518 ：デフォルトの名無しさん：2011/03/08(火) 03:10:56.55

間を取って、hgitおすすめ。

519 ：デフォルトの名無しさん：2011/03/08(火) 03:16:16.20

LLじゃなくCで実装されてるなら何でも良いよん

520 ：デフォルトの名無しさん：2011/03/08(火) 03:23:00.66

>>515
日本語のファイル名をつけたいなら、日本語WindowsでGitは化けるらしいよ。
UTF-8に対応したCygwinとかいうのなら、大丈夫らしいけど。

521 ：515 ：2011/03/08(火) 16:56:55.40

みなさんありがとうございます。
とりあえずgitの導入に挑戦してみようかと思います。

522 ：503：2011/03/13(日) 18:59:49.67

遅くなりましたが>>503です。
皆さんの言う通りファイルシステムの違いによるものでした。
ディスクイメージを作ってそこにcase-sensitiveなファイルシステムを
作ってみたところ、正しくチェックアウトできました。
ありがとうございます。

523 ：デフォルトの名無しさん：2011/03/14(月) 21:30:25.68

会社はSubversionなんだけど、
自分だけでもGit使ってみようと思って、
さっきgit clone仕掛けて帰ってきた。
明日出社したら終わってるかな?

524 ：デフォルトの名無しさん：2011/03/15(火) 02:03:33.89

別に前revision変換しなくてもよくね？

525 ：デフォルトの名無しさん：2011/03/15(火) 20:35:27.20

>>524
>>523ですが、会社行ったら
Out of memory!
になって死んでました。

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

これであとはgitの使い方に慣れて行けば、
あれやこれやの変更をパッチ形式で持ち続ける必要なくなるかな。
svnのブランチやら、他のツリーへのマージは
結局パッチにしてそれをあててからリリースになるんだろうけど。

526 ：デフォルトの名無しさん：2011/03/15(火) 20:48:14.12

>>525
git svn clone だよね？
git svn dcommit で Subversion 側にコミットもできるよ。

527 ：デフォルトの名無しさん：2011/03/15(火) 20:50:02.98

ああごめん。
一部だけ持ってきたって話なのか。無視してくれ。

528 ：デフォルトの名無しさん：2011/03/15(火) 22:58:20.64

529 ：デフォルトの名無しさん：2011/03/15(火) 23:04:25.71

～>>528のつづきです～

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

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

しばらく「trunk以外にはパッチ」対応しようと思いますが、
これじゃせっかくのコミットログが活かせなくて、めんどくさいですよね・・・
Gitはうまいことやってくれてるのになあorz

530 ：デフォルトの名無しさん：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

531 ：デフォルトの名無しさん：2011/03/18(金) 19:44:19.35

で？

532 ：デフォルトの名無しさん：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度でもコミットしないとブランチは作れないの？(´･ω･`)

533 ：デフォルトの名無しさん：2011/03/29(火) 18:00:45.59

ブランチ切る元がないんだから当たり前に見えるな

534 ：デフォルトの名無しさん：2011/03/29(火) 18:09:31.45

幹がなけりゃ枝も生えん

535 ：デフォルトの名無しさん：2011/03/29(火) 18:19:32.52

え、でもファイルがないとコミットできないんですよ(´･ω･`)
リポジトリを作ってすぐにブランチを切りたかったら空のファイルをコミットして、ブランチ切るのが作法なんでしょうか

536 ：デフォルトの名無しさん：2011/03/29(火) 18:23:52.79

つまり、空のディレクトリで git init しましたってことなん？
そして、空のまま git checkout しようとしたってことなん？

頭が空の人間なん？

537 ：デフォルトの名無しさん：2011/03/29(火) 18:26:23.54

>>535
ブランチの名前は後から自由に変えられる

538 ：デフォルトの名無しさん：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

539 ：デフォルトの名無しさん：2011/03/30(水) 04:22:50.15

>>535
Gitでは　ブランチ＝コミットに対する別名　なので、
ブランチを"切る" というような動詞から連想するようなことは起こっていない。

どうしてもやりたいなら、こうかな
git init
git symbolic-ref HEAD refs/heads/dev-branch

540 ：デフォルトの名無しさん：2011/04/01(金) 01:09:49.43

特定のファイルの追加や削除の追跡をしたいのですがよい方法はないですか？
知りたいのはどのリビジョンで追加や削除したのかという情報です
git blame でファイルを指定したらバイナリファイルのせいか画面がぐちゃぐちゃになってひどいことになりました
git blameはソースの変更を追いかけるものだからバイナリはお門違いなのでしょうけど

541 ：デフォルトの名無しさん：2011/04/01(金) 01:18:25.90

普通にi git log filename じゃダメなん？

542 ：デフォルトの名無しさん：2011/04/01(金) 16:38:06.84

>>536
そうですね空のままは変ですね

>>537-539
あーなるほど
ブランチやタグはコミットに名前をつけているんだということをわかったつもりだったのに理解していませんでした
コミットした後からでこちらの想定の使い方的に問題ないようでした
ありがとうございました

543 ：デフォルトの名無しさん：2011/04/07(木) 21:40:35.74

現在のファイルにおいて、
その行がいつ変更・追加されたかはgit blameでわかる
・・・と本を読んで知りました。
逆に、昔あったはずの行が削除されたのがいつなのか
を知る方法はありますか？

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

git logの-pオプションで表示されるパッチ部分に
git logの--grepオプションが適用されてくれれば、
もう少し手間が省けそうと思って試してみましたが、
そんな風には動いてくれませんでした。

544 ：デフォルトの名無しさん：2011/04/07(木) 23:09:12.42

>>543
俺もそういう時 git log -p してた。何か方法があるなら知りたいな。

545 ：デフォルトの名無しさん：2011/04/08(金) 00:40:04.26

>>543
git log -S"〈文字列〉"

で、〈文字列〉が追加または削除された履歴を確認できる

546 ：デフォルトの名無しさん：2011/04/08(金) 06:01:22.89

そんな方法があるんですね！
ちょっと調べてみます。ありがとうございました。

547 ：デフォルトの名無しさん：2011/04/08(金) 22:39:43.00

>>545
うわこれめっちゃ便利だ！！！
ありがとう！！！

548 ：デフォルトの名無しさん：2011/04/09(土) 06:49:06.41

githubでpullリクエストもらった時、複数のコミットが含まれてるのの１つだけマージするとか可能でしょうか？

549 ：デフォルトの名無しさん：2011/04/09(土) 07:31:38.51

>>548
途中までOKなのならその位置を指定してマージでいけるけど、歯抜けだと cherry-pick ですな。
ただし、つまみ食いしても問題のないパッチシリーズじゃないと、おかしなことに。

もしpullリクエストしてる側がまるごと取り込んで欲しいと考えてるようであれば、
まるごとのマージは出来ない理由を示して、惜しいのであれば一部修正してもらったら
良いのではないでしょうか。そしたらまるっとマージしてお互いにハッピー。

550 ：デフォルトの名無しさん：2011/04/09(土) 16:52:11.50

>>549
ありがとうございます、途中までは採用したいので、位置指定するマージのやりかたを調べてみます。

551 ：デフォルトの名無しさん：2011/04/13(水) 18:55:59.16

全ブランチにmasterの変更をマージする方法はありますか?
いまのところ、
git branchでブランチのリストを表示させて、それを見てから、

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

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

もっと普通はこういうふうにやる、
というのがあれば、教えていただけませんか？

552 ：デフォルトの名無しさん：2011/04/13(水) 19:35:25.42

rebase？

553 ：デフォルトの名無しさん：2011/04/13(水) 19:41:20.13

>>551
hookかな
なんにしてもコンフリクトする可能性は考えないといけないが

554 ：デフォルトの名無しさん：2011/04/14(木) 20:31:46.66

>>551です。
ありがとうございました。
たぶん私がまずやるべきはrebaseですね。
それをhookで自動化できるかも...
という感じでしょうか。
ちょっと調べてみます。

ありがとうございました。

555 ：デフォルトの名無しさん：2011/04/15(金) 03:22:29.99

git-now！

556 ：デフォルトの名無しさん：2011/04/16(土) 14:48:22.18

git nowってどの辺が便利なん？

557 ：デフォルトの名無しさん：2011/04/16(土) 16:00:50.59

そんなコマンドないよ

558 ：デフォルトの名無しさん：2011/04/16(土) 16:12:08.75

これかな？
http://d.hatena.ne.jp/sinsoku/20101208/1291770514

559 ：デフォルトの名無しさん：2011/04/16(土) 16:47:06.76

stash知らないのか

560 ：デフォルトの名無しさん：2011/04/18(月) 00:00:18.33

stashはうっかりstash clearとかしちゃうと大変だからコミットにしてるとかかな
俺はgit co -b tmpとかやってそっちに適当コミットを連発するのでgit-nowの便利さがわからん

561 ：デフォルトの名無しさん：2011/04/18(月) 00:36:36.28

マジでログメッセージ入れる意味すら無いのなら commit -m wip とかでいい。
コミットにも日付含まれるってのに、ログメッセージ`date`にするのは意味不明。
さらにそれを意味のあるコマンドみたいにして命名するのも意味不明。
単になう言いたいだけちゃうん？

562 ：デフォルトの名無しさん：2011/04/18(月) 00:54:15.20

いいんじゃね？リズムよく
git now
を使ってコミットすれば。

563 ：デフォルトの名無しさん：2011/04/18(月) 08:17:18.20

俺もstash使わずたいていwip branchだな。
stashの概念がすごくad-hocな感じがする。

564 ：デフォルトの名無しさん：2011/04/18(月) 08:49:12.98

git コマンド関係ない質問

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

バージョン管理に関して、issue（やpull request）を出す側が気にする必要はありませんか？

565 ：デフォルトの名無しさん：2011/04/18(月) 08:57:25.18

>>564
基本的には、個々の内容が妥当だという自信があるなら全て出すべき
たとえ自分の issue で 2 ページ埋まってもね
あれは known bugs な広報欄の役目も果たしてるから、不具合情報は共有されるべき

ただ
「issue は 0 にしてから次バージョン出すよぉ」
という潔癖さんが開発に混じってると問題はややこしく…ｗ

566 ：デフォルトの名無しさん：2011/04/18(月) 08:59:55.48

出すのは勝手(むしろ歓迎)だが、出し方に気を付けないと、シカトされるか
BL入りだろう。相手も人間だ。つまり付随メッセージの書き方の問題。

ただ、Forkされたものにいちゃもんつける権利はFork元にはあるまい。
それがGithubってもんだと思う。なのでいじったものをForkしてコミットするのがよろしかと。

567 ：デフォルトの名無しさん：2011/04/18(月) 09:24:42.35

たとえ嫌われても、差分コードを公開さえしてれば「いつのまにか」直ってることはよくある
ぶっちゃけ最終的には配布ライブラリ本体がよくなってれば万事OKなわけで

なお、文字エンコーディング関連の話を英語圏の作者さんに振るとたいてい嫌われる
テストに書いてある文字が読めないから何をやってるかわからないってさ
安心しろアスキー環境でも表示できるようバイナリリテラルで書いたから俺も読めん

568 ：デフォルトの名無しさん：2011/04/18(月) 09:40:22.93

コード書くことで別の方法が思いついたりくっついたり分かれたり本質でないことに気づいたりするもんなので、
とりあえずpull requestする気でフォークしてコミットして公開するのがいいな

569 ：デフォルトの名無しさん：2011/04/18(月) 19:00:41.40

BLってブラックリストのことか。普通にボーイズラブかと思ったよ。

570 ：デフォルトの名無しさん：2011/04/18(月) 19:23:45.12

ボーイズラブでも普通に意味は通るな。

通んねえよ！

571 ：デフォルトの名無しさん：2011/04/18(月) 20:23:52.97

てっきり次にこういうコマンド打つとこういう結果になるよって suggest してくれる機能かと思ってた > git now

572 ：デフォルトの名無しさん：2011/04/19(火) 06:19:03.99

git-emacs で直接コミットメッセージ開き直して git commit -a --amend してくれる機能とかないの
M-x git-amend-commit は変な動作だし

573 ：デフォルトの名無しさん：2011/04/19(火) 08:09:59.38

emacsよく知らないんだけど、いろいろあるみたいね
http://d.hatena.ne.jp/gom68/20090524/1243170341

574 ：デフォルトの名無しさん：2011/04/19(火) 09:34:12.47

GNU EmacsはBazaarで開発されています。
Bazaarに切り替えて下さい。

575 ：デフォルトの名無しさん：2011/04/19(火) 09:57:31.71

Mercurial チートシート http://troter.jp/mercurial-cheatsheet/#sec-1
＞1 はじめに
＞mercurialのチートシートがgithubに上がっていることに疑問を覚えないこと。

576 ：デフォルトの名無しさん：2011/04/19(火) 23:39:07.16

>>574
とは言えemacs向けのbzrに特化したelが有る訳でも無し。

577 ：デフォルトの名無しさん：2011/04/20(水) 14:01:19.09

GitHubで、いくつかプルリクエストしてメインに受け入れられました

…で、自分の公開エリアに残ったブランチどうしましょう
消しちゃっていい？
っていうかプルリクエストの数だけ加速度的に公開済みブランチが増えていく気がするんですが
皆さんどうやって管理してるもんなんでしょうか

578 ：デフォルトの名無しさん：2011/04/20(水) 14:32:49.63

プルとプッシュがよくわかりません。

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

で、ローカルでコミットしたあと元のリモートリポリトジに更新分を
送りつけるのがプッシュでいいのかな？

579 ：デフォルトの名無しさん：2011/04/20(水) 14:42:18.38

先輩方、どうか助けてください
WindowsにGitを入れました
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/gittutorial.htmlを元にGitを覚えています
デスクトップのGit Bashアイコンを起動して
cd \code\java\testに移動して
git initをして
git add .をやったあとに
git commitをしたら
エディタが起動して
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Committer: unknown <ユーザー名@.(none)>
#
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: Test.class
# new file: Test.java
#
って表示されました。
wikiのコミットコマンドを実行すると、コミットメッセージの入力が求められます。その後、プロジェクトの最初のバージョンが git に格納させます。」ってところでつまづいてます。
ここからどうしたらよいのか判りません
どなたかお力添えをお願いいたします

580 ：デフォルトの名無しさん：2011/04/20(水) 14:56:10.10

viの使い方覚えましょう
それかデフォルトのエディタ変える
それかgit commit -m"aaa"ってやる

581 ：デフォルトの名無しさん：2011/04/20(水) 15:05:32.27

>>578
カタカナだとわけわかめになる
pull は英単語
push も英単語

582 ：デフォルトの名無しさん：2011/04/20(水) 15:09:30.06

>>577
orgissue12みたいなブランチ切ってpull requestするようにすれば後から見てもわかりやすい。
上流にマージされたなら消しても問題ないし残してても問題ないし好きにすればいいと思う。

583 ：デフォルトの名無しさん：2011/04/20(水) 15:13:18.79

>>580
ありがとうございます！！！！これでコミットできました！

584 ：デフォルトの名無しさん：2011/04/20(水) 15:19:39.49

pull は（サーバから）引っ張り込むんだよ
push は（サーバへ）押し出すんだよ

git pull はどちらかというとオリジナルとの同期コマンドだな…

585 ：デフォルトの名無しさん：2011/04/20(水) 15:20:51.34

>>584サンキュ、理解できた！

586 ：デフォルトの名無しさん：2011/04/20(水) 15:44:00.32

バージョン管理初心者はGitとSVNどっちがお勧めですか？

587 ：デフォルトの名無しさん：2011/04/20(水) 15:49:27.45

>>586
Bazaar

588 ：デフォルトの名無しさん：2011/04/20(水) 15:56:31.70

さすが兄者ｗ

589 ：デフォルトの名無しさん：2011/04/20(水) 16:42:20.80

>>586
ＧｉｔとSVNという選択の仕方がすでに間違っている気がするｗ
Ｇｉｔと何かというならMercurialとかBazaarじゃね。

590 ：デフォルトの名無しさん：2011/04/20(水) 16:46:18.50

gitとsvnの間で悩む時点で、分散かどうかなんてどうでもいいってことだろう。
だったらsvn一択じゃね？信頼感がぜんぜん違うよ！

591 ：デフォルトの名無しさん：2011/04/20(水) 16:48:04.39

ひとまずDropbox使ってソースの置かれているディレクトリを対象に含めると良い。
何もせずにDropbox側のSVNでバージョン管理してくれる(20個程度だけど)。

ほとんど手間なしでよいから物臭なひとにはおすすめだ。

592 ：デフォルトの名無しさん：2011/04/20(水) 16:48:36.16

用途を書いておきます
ファイルをバックアップするのが目的なのですが
例えば事故でファイルが消滅（他のファイルの内容で上書きとか、ファイル自体をゴミ箱にいれて戻せなくなった等）に備えて、バックアップを取ることです

593 ：デフォルトの名無しさん：2011/04/20(水) 16:52:27.76

>>592
rsync

594 ：デフォルトの名無しさん：2011/04/20(水) 16:53:26.13

ならsvnじゃね？
gitというか分散型だとリポジトリも同じ場所にできるから、ディレクトリごとごっそり消してしまったりしたときに弱い。

ただ、バックアップだけなら素直にOSのバックアップツールを使ったほうが小回りが効くような。

595 ：デフォルトの名無しさん：2011/04/20(水) 17:04:02.50

>>592
その用途なら、俺もDropbox進めるわ。
1ファイルのサイズがでかいというなら外付けHDDと差分バックアップソフトかな。

どうしてもこの系統のソフトが使いたいならSubversion（winならTortiseSVN）で良いんじゃね。

596 ：デフォルトの名無しさん：2011/04/20(水) 17:15:35.78

Dropboxって無料版だと30日で消されるんだって

597 ：デフォルトの名無しさん：2011/04/20(水) 17:28:08.40

話の途中で申し訳ないが質問していいっすか？
Gitで良く使うコマンドって何？

598 ：デフォルトの名無しさん：2011/04/20(水) 17:43:11.84

>>596
いや、普通に毎日ログインするだろｗ
てかおれの1年以上ほかしてたけど内容のこってたわ。

599 ：デフォルトの名無しさん：2011/04/20(水) 18:30:34.11

>>598
古い変更履歴が消えるってことでしょ

600 ：デフォルトの名無しさん：2011/04/20(水) 21:58:05.41

>>597
1. git rebase --continue
2. git checkout
3. git rebase (-i)

マジにネタレス。

601 ：デフォルトの名無しさん：2011/04/20(水) 22:07:14.59

st(atus)だな

レスにマジネタ

602 ：デフォルトの名無しさん：2011/04/20(水) 22:20:22.38

git remote update --prune もよく使う。

603 ：デフォルトの名無しさん：2011/04/20(水) 22:23:24.15

たぶんgit grepとgit log foo/bar.txt

604 ：デフォルトの名無しさん：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なんてのが明示的に出て来るのか、
また、なぜこれでブランチを作る事になるのか分かりません。　

605 ：デフォルトの名無しさん：2011/04/20(水) 23:10:52.89

>>604
git pushのmanページに詳しく書いてあるよ。

なぜpushで新規作成する時だけrefs/headsとフルで書かないといけないかというと、
フルで指定しないとどこに作っていいか曖昧だからだろう。まあ普通は refs/heads/
ですよね、ってことではあるけど、そうじゃない場合もありうるので。

606 ：デフォルトの名無しさん：2011/04/20(水) 23:43:31.99

>>561
このwipってどういう意味なんだ
ぐぐったら一時的な(gitで言えばstash的な)作業やブランチ、コミットに使われているみたいだけど
ジャーゴン？

607 ：606：2011/04/20(水) 23:45:56.10

ふつうに英語の略語だったわ
wip=work in progress
作業中

608 ：デフォルトの名無しさん：2011/04/20(水) 23:46:00.99

>>600
え？cloneは？

609 ：デフォルトの名無しさん：2011/04/21(木) 00:12:36.21

cloneはリポジトリ作成時くらいだからよく使うもんでもないだろう

610 ：デフォルトの名無しさん：2011/04/21(木) 01:09:31.21

>>599
有料なら大丈夫

611 ：604：2011/04/21(木) 01:32:36.87

>>605
ありがとうございます。　では、これを応用して、既存のどこかのコミットにtagを打って
そこからブランチを切るというのをリモートに対して行うというのはこういう感じが
正当でしょうか？

$ git tag 1.3.0 <hash> # 1.3.0 はここと決める
$ git push --tags
$ git push origin 1.3.0:refs/heads/1.3-maint # 1.3.0を頭に1.3.* の保守ブランチを作る。

612 ：デフォルトの名無しさん：2011/04/21(木) 07:54:20.34

git svnで、SVNレポジトリをcloneして使ってるんだけど、
SVNだと、ローカル開発環境用に設定ファイルを書き換えておいて放置、みたいな
運用ができるけど、Gitではどうすべきなんだろう。
git svn rebaseすると、updateしてないって怒られちゃうし。

613 ：デフォルトの名無しさん：2011/04/21(木) 08:02:15.70

>>612
master は svn-rebase & svn-dcommit 専用ブランチとして割りきって
俺作業用ブランチの上であれこれするのがよい。

俺の場合、dcommit する際には cherry-pick が基本だな。
git-svn と暮らすには、rebase 基本のワークフローにするのがベターと思う。

614 ：デフォルトの名無しさん：2011/04/21(木) 22:19:31.29

>>609
git clone を cvs checkout と同じ用途で使うバカもいるみたいだぞ。
これが一番確実、とか意味不明なこと言って。

615 ：デフォルトの名無しさん：2011/04/21(木) 22:50:36.78

えﾞ、俺バカだ。
じゃあ作業コピー作りたいときはどうするの？明示的にgit remote add & fetch？

616 ：デフォルトの名無しさん：2011/04/21(木) 23:06:49.83

>>613
gitはリモートのファイルにオレオレパッチやオレオレ修正あてたまま、
公式のリリースに追従していくとが楽でいいよね
これだけでもsvnから移行したかいがあった
svnでもできるかもしれないし、gitというか分散型の特徴なのかもしれないけれど

617 ：デフォルトの名無しさん：2011/04/22(金) 08:02:28.33

>>613
>>616
なるなる。ありがとう。

618 ：デフォルトの名無しさん：2011/04/22(金) 09:48:13.13

地震に備えてソースコードをバックアップして置きたいのですが
GITでオンライン上で非公開でソースコードを置ける無料のサイトってありますか？

619 ：デフォルトの名無しさん：2011/04/22(金) 09:54:23.06

DropBox等につっこむとか

620 ：デフォルトの名無しさん：2011/04/22(金) 12:50:36.57

>>618
mercurialに変換してbitbucket

621 ：デフォルトの名無しさん：2011/04/22(金) 13:33:51.09

>>614
答えは？

622 ：デフォルトの名無しさん：2011/04/22(金) 17:58:49.88

>>611
正当というのがどういうのか分からないけど、
ローカルにタグ、リモートにブランチが欲しいなら、
そういう感じで良いんじゃないですかね。

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

>>612
stashを使うというのも手ですね

623 ：デフォルトの名無しさん：2011/04/23(土) 07:56:03.50

>>618
Gist

624 ：デフォルトの名無しさん：2011/04/23(土) 08:45:16.80

>>623
あの"Private"はURLが分かれば誰でもアクセスできるよ

625 ：デフォルトの名無しさん：2011/04/23(土) 12:06:08.47

>>618
assemblaはどう？

626 ：デフォルトの名無しさん：2011/04/23(土) 18:14:18.55

バージョン管理というものはいまいちよく分かりません
まず、Gitを入れました
リポジトリを作成しました（おまじないみたいなものでしょうか？）
書いたソースコードをコミットしました（これはソースをバックアップするって意味であってますか？）
取り出すときに、○番目のソースコードを取得する方法が分かりません
あと、入門サイトとかでは取得するときフォルダを作成しているのですが、書いているファイルに読み込ませられないのでしょうか？

627 ：デフォルトの名無しさん：2011/04/23(土) 18:21:33.84

>>626
そもそも「なぜバージョンを管理する必要があるののか」というのを先に学んだ方が良いかも。
必要に迫られてバージョン管理しようと思った人は「なぜ」が分かるから、一つ一つの作業の
意味を掴みやすい。

漠然と始めたりすると「なぜ」必要なのか分からないから、リポジトリ・コミット・履歴管理と
言った言葉で、バージョン管理ソフトが何をしようとしているのか理解できないのかも。

628 ：デフォルトの名無しさん：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/
こっちはコミットとは何か、とかいう基本から書いてあるぜー

629 ：デフォルトの名無しさん：2011/04/23(土) 18:28:10.68

atwikiの法は難しくて挫折しました（ぇ
もうかたほうのサイトで勉強してみたいと思います
６２７さん６２８さんありがとうございます

630 ：デフォルトの名無しさん：2011/04/24(日) 16:23:10.58

git branch test
したあとで
git branch test/foo1
すると怒られて切ないです
なんとかなりませんか
ブランチ名の区切り子に / を使うこと自体がアレなのかもしれませんが

631 ：デフォルトの名無しさん：2011/04/24(日) 17:21:11.86

それはtouch fooしたあとmkdir fooしたら怒られるってくらい理不尽だと思うｗ
/以外の記号じゃダメなん

632 ：デフォルトの名無しさん：2011/04/24(日) 17:29:22.25

/ は git branch のとき内包的関係が見やすいんだよね
　test_vol1/foo
　test_vol1/bar_baz
：：もよくね、と思ったんだがファイルシステムの制限で使えなかったり
仕方ないので
　test_vol1-foo
　test_vol1-bar_baz
というようにしてる
微妙に見にくい

633 ：デフォルトの名無しさん：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 でコミットメッセージを編集しなおしてる。

634 ：デフォルトの名無しさん：2011/04/24(日) 19:44:54.94

>>624
知らなかった！！

635 ：デフォルトの名無しさん：2011/04/24(日) 22:03:36.39

>>624
mjd?

636 ：デフォルトの名無しさん：2011/04/24(日) 22:55:16.92

>>635
http://support.github.com/discussions/gist/119-private-gist-is-not-secure

637 ：デフォルトの名無しさん：2011/04/24(日) 23:03:57.67

>>632
test_vol1が無ければ、これはできるでしょ
test_vol1/foo
test_vol1/bar_baz

638 ：デフォルトの名無しさん：2011/04/25(月) 03:15:01.66

>>636
Megauploadにプライベートファイル置いた時並にひでぇｗ
↑個人ストレージのつもりで借りたら丸見えだったでござる

639 ：デフォルトの名無しさん：2011/04/25(月) 08:00:29.25

ttp://article.gmane.org/gmane.comp.version-control.git/171996
1.7.5ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

640 ：デフォルトの名無しさん：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つだけを適用するのか。
詳しい方おしえてください。

641 ：デフォルトの名無しさん：2011/04/28(木) 17:18:16.56

>>640
とりあえずやってみようぜ？
rebaseが自動判定してくれるのは知ってるけど、mergeはどうだったっけなぁ。

642 ：デフォルトの名無しさん：2011/04/28(木) 17:48:46.24

>>641
Gitはまだ触ったことないんでちょっと試すというわけにはいかないんですが、
マージがどのくらい賢いのかがわかんなくて、すごく賢いようだったら
Gitの勉強をしようかなと思って、その判断をするために質問しました。
>>640が分かる方いましたらよろしくお願いします。

643 ：デフォルトの名無しさん：2011/04/28(木) 18:20:52.96

>>642
ちょっと触るぐらい簡単だろうよ…cherrypickとか知ってるんなら他のVCS使ってるんだろ。
何にもしないでただ教えろって知恵袋かよ。

マジレスするとmergeは3wayマージするだけなので間のコミットとか関係ない。
マージベースがちゃんと取れれば、同じコミットが含まれてたりする場合でも
たいていうまくいく。あまり行が近かったりすると別の意味でconflictになるけど。

644 ：デフォルトの名無しさん：2011/04/28(木) 23:08:57.87

dropboxって30日で消えるんですか？
コードのバックアップに適しているところって他にありますかね
半年ぐらいネットから離れる場合はどこのオンラインストレージがいいでしょうか？
無料でお願いします

645 ：デフォルトの名無しさん：2011/04/28(木) 23:15:58.51

dropbox内のフォルダをgitやらなんやらでバージョン管理すればいいよ

646 ：デフォルトの名無しさん：2011/04/28(木) 23:23:11.21

ああ，専ブラで横のタブにDropbox総合スレがあったから見間違えた
Dropboxは古いバージョンのファイルが30日で消えるだけで，全部のファイルはずっと残ったままだぞ
バージョン情報を保ちたいなら，リポジトリ自体をDropbox上に作れという話

647 ：デフォルトの名無しさん：2011/04/28(木) 23:31:45.63

ということは常に最新のファイルは消されないってことですね
でも半年後にサービスが終了したら怖いな

648 ：デフォルトの名無しさん：2011/04/28(木) 23:56:58.01

>>647
一時期、cronで定期的にzipして自分のgmail口座にメールで送るというのを
バックアップとして使ってた。　

649 ：デフォルトの名無しさん：2011/04/29(金) 00:05:19.85

Git+GAEで管理できたらいいな

650 ：デフォルトの名無しさん：2011/04/29(金) 09:29:23.51

>>647
そんな心配していたら、何も使えないだろ。
ローカルのHDDが吹っ飛ぶ可能性だってあるんだぜ。

651 ：デフォルトの名無しさん：2011/04/29(金) 10:46:27.58

テスト中 utf8-git-on-windows
http://code.google.com/p/utf8-git-on-windows/

652 ：Perl忍者：2011/04/29(金) 23:45:00.87

githubとsvnの違いを説明してください
わかりません
イマイチよくわかりません
メリットデメリットなど

653 ：デフォルトの名無しさん：2011/04/29(金) 23:45:53.95

githubがphpでsvnがperlだ

654 ：Perl忍者：2011/04/29(金) 23:46:53.02

svnっていうやつはサーバー立てるんですか？
githubっていうのはWEBから操作できるやつですか？

バージョン管理システムについておしえてください

655 ：Perl忍者：2011/04/29(金) 23:47:15.60

>>653
まじめにこたえろはげ

656 ：Perl忍者lvl4 ◆M5ZWRnXOj6 ：2011/04/29(金) 23:48:18.84

偽きめえなw
まぁこの偽かわいそうだから
教えてやればw

657 ：Perl忍者：2011/04/29(金) 23:48:43.27

はい　教えてください

658 ：Perl忍者：2011/04/29(金) 23:52:18.38

教えろよボケ

659 ：Perl忍者：2011/04/30(土) 01:20:47.51

はよ教えろｗ

660 ：デフォルトの名無しさん：2011/04/30(土) 09:54:17.96

>>659
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

661 ：デフォルトの名無しさん：2011/04/30(土) 16:43:17.27

>>633
core.editorに好きなテキストエディタを設定すればよろし
コミットログに使っている文字コードを指定するのを忘れないようにしてね
テキストエディタの代わりにシェルスクリプトやバッチファイル経由で立ち上げてもいい

適当にググッてきた参考サイト
gitで秀丸を使う方法 - hClippr編集室ブログ
http://d.hatena.ne.jp/unsignedint/20090303/1236138302

662 ：デフォルトの名無しさん：2011/04/30(土) 22:02:15.20

宣伝成功！！ｗｗｗ

663 ：デフォルトの名無しさん：2011/05/01(日) 15:28:09.15

dropboxでコードのバックアップ取っている方に質問です
dropboxで提供しているクライアントはインストールして使ってますか？

664 ：デフォルトの名無しさん：2011/05/01(日) 15:54:20.62

むしろ、使わないでどうするんだｗ
手動でUpDownに同期までするならdropboxを使う理由もない。

665 ：デフォルトの名無しさん：2011/05/01(日) 16:48:55.30

C:\Users\ユーザー名\Dropboxが出来たけどいまいちよくわかんないし
このフォルダだけしか同期されないようになってるんだよね？
保存して右クリックで同期するとか、ファイルを保存したら勝手に同期そういうのだと思ってた
毎回dropboxのフォルダに保存したいファイルをコピーするのめんどくせえ

666 ：デフォルトの名無しさん：2011/05/01(日) 17:03:23.57

Gitスレでやることじゃねえだろ
どっかいけ

667 ：デフォルトの名無しさん：2011/05/01(日) 17:06:02.81

>>665
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

668 ：デフォルトの名無しさん：2011/05/01(日) 17:24:35.63

なんでdoropboxスレで聞かないの？

669 ：デフォルトの名無しさん：2011/05/01(日) 20:29:37.81

VS2008にgit extentionsつっこんだんだけど、
VSのプラグインから見るとcygwinからコミットしたログが文字化けする。
エンコードをUTF-8にすると直るけど、こんどはCP932のファイル差分が文字化け。
なんか方法はないもんかね？

670 ：デフォルトの名無しさん：2011/05/01(日) 22:55:27.29

コミットログを書くときのエンコーディングを統一するか、
Textconvにnkfを使ってコミットログを出力するときのエンコーディングを統一すれば良いんでは？

671 ：デフォルトの名無しさん：2011/05/02(月) 08:23:56.45

リモートのブランチを全部再現することってできませんか？
git clone したら master しか持って来れなくて困りました

672 ：デフォルトの名無しさん：2011/05/02(月) 08:34:05.59

git fetch --all
それが貴殿の望みどおりの動作をするとは思えん。

673 ：デフォルトの名無しさん：2011/05/02(月) 08:34:47.08

書いたあとで思ったが
git branch -r
を実行したことがあるのだろうか?

674 ：デフォルトの名無しさん：2011/05/02(月) 09:00:43.41

>>671
git branch は引数を2つ取ることができる(普段は1個)
git branch hoge origin/hoge
とするとリモートにあった hoge が監視下に入る
リモートになにがあったかの情報は git clone した時点で既に手元に来てるので
git branch -a でもして表示しれ

一発ではできない気がするので、適宜使うブランチだけ再現

675 ：デフォルトの名無しさん：2011/05/02(月) 10:25:52.47

>>665
Dropboxは場所が固定だが、
SugarSyncみたいな任意のフォルダを同期できるサービスもあるよ。

676 ：デフォルトの名無しさん：2011/05/02(月) 14:26:16.02

>>646
>バージョン情報を保ちたいなら，リポジトリ自体をDropbox上に作れという話
これやってるけど無茶苦茶便利。
自分の開発機だと別のマシンでもチェックアウトする必要ないんだもん。

677 ：デフォルトの名無しさん：2011/05/02(月) 16:19:31.09

>>676
それって多人数開発でもうまくいくの？
なんだか一人開発が前提のように見えるけど。

678 ：デフォルトの名無しさん：2011/05/02(月) 16:45:30.32

publicで共有すればできるだろ

679 ：デフォルトの名無しさん：2011/05/02(月) 17:09:53.63

>>677
もちろんDropboxは一人だけですよ。
何のための分散型バージョン管理なんですかっ

680 ：デフォルトの名無しさん：2011/05/02(月) 18:31:14.55

dropboxを一人で使うことと分散型に関連性があるのか。

681 ：デフォルトの名無しさん：2011/05/02(月) 18:46:56.77

1つのdropboxを多人数で使うのは集中型的手法。
多数のdropboxを多人数で使うのは分散的手法。

682 ：デフォルトの名無しさん：2011/05/02(月) 20:07:14.88

多数のdropboxを使うと言ったって共有する部分は集中型じゃん。

683 ：デフォルトの名無しさん：2011/05/02(月) 21:51:34.46

集中しなくてもいいんですよ

684 ：デフォルトの名無しさん：2011/05/02(月) 23:04:07.25

なんのスレ

685 ：デフォルトの名無しさん：2011/05/02(月) 23:46:21.89

ここは初めてか? ケツの○を抜けよ.

686 ：デフォルトの名無しさん：2011/05/02(月) 23:48:39.80

バザアッー！

687 ：デフォルトの名無しさん：2011/05/02(月) 23:50:16.66

>>682
「多数」＝多○○数○
なるほど

688 ：デフォルトの名無しさん：2011/05/04(水) 11:06:14.15

dropboxでgitを管理する方法を教えてください
dropboxでインストールしたらC:\dropboxが出来ました
ここにgitのリポジトリを作ればいいんですか？
あと、コミットはどこにやればいいのでしょうか？
dropboxのサイトのほうですか？それともc:\dropbox内のgitのリポジトリに対してですか？
それと、30日でファイルが消えるってありますが、30日以内にファイルをコミットし続けないといけないのでしょうか？
そのへんはマクロとか使えば何とかなりますが・・・

689 ：デフォルトの名無しさん：2011/05/04(水) 11:22:02.21

馬鹿には無理

690 ：デフォルトの名無しさん：2011/05/04(水) 11:25:51.51

しね

691 ：デフォルトの名無しさん：2011/05/04(水) 11:40:33.59

>>688
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

692 ：デフォルトの名無しさん：2011/05/04(水) 12:43:06.72

何故彼はdropboxでgitを管理しようと思ったのか・・・w
dropboxでgitを管理する上で特有の何かを聞きたいわけでもなさそうだし

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

それから、gitのリポジトリをDropboxで管理する方法が適切かどうか判断したほうがいい
俺ならgitのリポジトリをDropboxには置かないがこれは俺の判断だし

693 ：デフォルトの名無しさん：2011/05/04(水) 12:57:43.83

だってさ無料で非公開で管理できるサーバが欲しかったんですよ
俺は金がないから自分でどりょくしてここまで来たのですよ

694 ：デフォルトの名無しさん：2011/05/04(水) 13:07:51.10

>>693
つ>>620

695 ：デフォルトの名無しさん：2011/05/04(水) 13:23:35.48

>>688
> ここにgitのリポジトリを作ればいいんですか？
まずやってみろよ

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

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

> それと、30日でファイルが消えるってありますが、30日以内にファイルをコミットし続けないといけないのでしょうか？
Dropboxスレで聞けよ

696 ：デフォルトの名無しさん：2011/05/04(水) 13:34:16.16

やりたいんですけど壊れたら怖いので聞いてみたのですよ
お年玉も使っちゃったし自分でパソコン変えないしまだ小５だから

697 ：デフォルトの名無しさん：2011/05/04(水) 13:48:56.17

しね

698 ：デフォルトの名無しさん：2011/05/04(水) 13:56:43.47

おじさん、しねって言葉は使っちゃダメですよ

699 ：デフォルトの名無しさん：2011/05/04(水) 14:44:44.39

バージョン管理システム動かしたくらいでPCが壊れるわけねーだろ
Gitどうこう以前に頭が弱すぎて話にならん

700 ：デフォルトの名無しさん：2011/05/04(水) 16:47:29.75

低脳に居座られてこのスレも大変だなｗ

701 ：デフォルトの名無しさん：2011/05/04(水) 17:02:13.91

おまえもな

702 ：デフォルトの名無しさん：2011/05/04(水) 19:47:40.06

一昔前の週刊アスキーに
「Firefoxの新バージョンのインストールは最悪OSの入れなおしも覚悟しといて」
とかさらりとすごいこと書いてあったな(板違いｽﾏｿ)

703 ：デフォルトの名無しさん：2011/05/04(水) 20:37:44.38

はあ？

704 ：デフォルトの名無しさん：2011/05/04(水) 20:43:39.09

>>703
うん、にわかには信じられないだろ？
でも書いてあったんだよマジで…

705 ：デフォルトの名無しさん：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/

706 ：デフォルトの名無しさん：2011/05/04(水) 23:07:31.48

WinだけどFirefoxってブラウザのくせにインストールするとちゃっかりサービスに登録しちゃうんだよな

707 ：デフォルトの名無しさん：2011/05/04(水) 23:57:44.50

えっ

708 ：デフォルトの名無しさん：2011/05/05(木) 00:01:22.59

えっ

709 ：デフォルトの名無しさん：2011/05/05(木) 00:03:15.61

えっ

710 ：デフォルトの名無しさん：2011/05/05(木) 00:10:14.05

知らないなら自分で確認したらどうだ

711 ：デフォルトの名無しさん：2011/05/05(木) 06:17:18.02

えっ

712 ：デフォルトの名無しさん：2011/05/05(木) 07:10:57.26

えっ

713 ：デフォルトの名無しさん：2011/05/05(木) 07:11:22.23

最近このスレも活発になってきましたね！！

714 ：デフォルトの名無しさん：2011/05/05(木) 07:21:39.30

かなりどうでもいいけどPerl忍者ってさ
http://blog.plaync.jp/giko/302948.slog

715 ：デフォルトの名無しさん：2011/05/05(木) 08:43:29.54

えっ

716 ：デフォルトの名無しさん：2011/05/05(木) 11:57:28.48

馬鹿の一つ覚え

717 ：デフォルトの名無しさん：2011/05/05(木) 12:53:38.58

えっ

718 ：デフォルトの名無しさん：2011/05/05(木) 15:15:48.56

えっ

719 ：デフォルトの名無しさん：2011/05/05(木) 15:40:09.17

https://github.com/treeboa

720 ：デフォルトの名無しさん：2011/05/05(木) 21:47:51.99

うわ、糞の役にも立たない手抜きソフトしかない(棒

721 ：デフォルトの名無しさん：2011/05/06(金) 00:01:34.59

>>705
ダム板はいいとして実質マスコットはoctocatだからな・・・

722 ：デフォルトの名無しさん：2011/05/06(金) 00:24:02.96

だからおくときヤトなんでしょ
おもしろくないけど

723 ：デフォルトの名無しさん：2011/05/06(金) 01:54:46.92

マスコットはどーもくんだろ

724 ：デフォルトの名無しさん：2011/05/06(金) 10:11:43.71

>>722
やっとわかったwww

725 ：デフォルトの名無しさん：2011/05/08(日) 18:51:02.84

makeするといくつかの実行ファイルができます。
UNIX環境なので、exeのような拡張子がありません。
バイナリファイルを追跡から除外する良い方法はありませんか。

726 ：デフォルトの名無しさん：2011/05/08(日) 18:58:12.22

>>725
出力されるパスは決まってないの？

727 ：デフォルトの名無しさん：2011/05/08(日) 19:16:04.67

>>726
ファイル名を決め打ちできないこともないのですが、
開発しているうちにいろいろ変わるのです。
たとえば、main_foo, main_bar, main_baz, ... のように。
一方、main.c, main.h, ....などがいろいろあるので、
.gitignore に
main*
!*.c
!*.h
...
のように書けばいいのかな。

728 ：デフォルトの名無しさん：2011/05/08(日) 19:45:28.75

これまた随分と保守しづらい開発方法取ってんだねえ・・・ｗ

729 ：デフォルトの名無しさん：2011/05/08(日) 20:28:05.33

出力フォルダを別にするとかかなあ

730 ：デフォルトの名無しさん：2011/05/09(月) 01:09:01.19

>>728
>>729

なし崩し的に開発してきたので、自分でも少し整理が必要だと思いました。

731 ：679：2011/05/09(月) 15:56:41.95

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

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

Dropboxを使えば、一人で開発を始めるときに使い始めて
後でサーバを立てたときもその流れで環境を使い続けられると言うのがいい事かと。

732 ：デフォルトの名無しさん：2011/05/09(月) 17:03:17.89

そういう用途ならこれ便利かもね
ttp://uu59.blog103.fc2.com/blog-entry-9.html

733 ：デフォルトの名無しさん：2011/05/10(火) 00:26:48.98

>>731-732
リポジトリだけをDropboxにおくってこと？
これってリポジトリ壊れないのか。
検索したら、壊れるからとTrueCryptに入れてDropboxに入れている人がいた。
ようするに1つのディスクイメージに入れるってことだと思う。Dropboxは1ファイルでも差分同期してくれるから早いらしい。

734 ：デフォルトの名無しさん：2011/05/10(火) 04:21:52.82

そりゃリポジトリとDropboxの更新が非同期なんだから、中途半端にsyncしたあと
接続が切れたりしたら別マシンから見たとき壊れててもおかしくない
TrueCrypt使えば壊れないってのは理屈がわからないな

735 ：デフォルトの名無しさん：2011/05/10(火) 04:46:08.36

Dropboxよくわからないけど、手動で完全にSyncできるなら壊れにくくはなるのかな。

リポジトリをまるごとリモートマウントしたら、本末転倒な気もするけどねぇ。

736 ：デフォルトの名無しさん：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からコミットした行の部分は、表示されていることもあるようですが

737 ：デフォルトの名無しさん：2011/05/11(水) 23:38:56.61

>>736
それってまだコミットされてない行だよ。
git svnがうまくいってないんじゃない？

738 ：736：2011/05/12(木) 22:48:00.13

>>737
作業コピーのファイルは弄っていないです

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

git blame COMMIT_HASH.. -- filename

739 ：デフォルトの名無しさん：2011/05/13(金) 00:32:11.02

COMMIT_HASHにHEADって指定したらどうなる？

740 ：736：2011/05/13(金) 21:51:58.64

>>739
同じです・・・
Not Commited Yetの行ばかりになります

741 ：デフォルトの名無しさん：2011/05/13(金) 22:54:10.75

>>740
ちゃんとクリーンな状態なの？ git statusしてmodifiedとか出てない？

742 ：デフォルトの名無しさん：2011/05/14(土) 13:33:11.55

〇〇というブランチの××というファイルの内容を参照して書きたい、という場合に、うまい表示法はありませんか
ターミナルに表示されるだけでいいのですが

743 ：デフォルトの名無しさん：2011/05/14(土) 14:06:27.71

>>742
そんなあなたにgitg
いつもおそばにgitg
※ gitkでも可

ブランチ選んでコミット選んでtreeタブをクリックしてディレクトリたどってファイルをクリックするとあら不思議

744 ：デフォルトの名無しさん：2011/05/14(土) 14:17:16.05

>>743
うおー
なにこのものぐさソフト

745 ：デフォルトの名無しさん：2011/05/15(日) 14:01:13.40

>>742
git show branch:path

746 ：デフォルトの名無しさん：2011/05/15(日) 14:05:53.52

git checkout .
でコミット後のファイルの変更が全部なかったことになってコミット直後に戻るのはなんで？
っていうかオペミスが怖いんだけど

747 ：デフォルトの名無しさん：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

引っかかってる人は多い模様

748 ：デフォルトの名無しさん：2011/05/15(日) 15:15:04.33

バージョンいくつの話？
うちは1.7.5だけど全く同じことを昨日やって問題なかったが

749 ：デフォルトの名無しさん：2011/05/15(日) 16:09:42.54

うーんと、Ubuntu10.10 だから git 1.7.1 で、…うん、1年前のだな

750 ：デフォルトの名無しさん：2011/05/15(日) 19:51:19.21

>>746
カレントディレクトリ「.」にHEADのファイルを再帰的にチェックアウトしろ
ってことだから、当然そうなるもんだと思ってたけど・・・

751 ：デフォルトの名無しさん：2011/05/15(日) 21:22:52.33

てかcheckoutってそういうもんじゃないんだっけ

752 ：デフォルトの名無しさん：2011/05/15(日) 21:37:13.53

--force があっても良いかもと思わなくもない

753 ：デフォルトの名無しさん：2011/05/15(日) 22:00:00.04

>>746
git checkout ''
でも同じようになるね

754 ：デフォルトの名無しさん：2011/05/16(月) 00:17:15.24

質問です。

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

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

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

サブバージョンで「！」は変更したファイルなどにマークされていた思いますので、
poullしてきた瞬間になんらかの変更がなされてしまったということなのでしょうか？

755 ：デフォルトの名無しさん：2011/05/16(月) 03:54:03.30

autocrlfあたりが発動して改行コード変わってるんじゃね

756 ：デフォルトの名無しさん：2011/05/16(月) 06:03:17.93

そもそも git-chekcout はブランチ名とファイルパスの引数2つなのよ
珍しく、機能を分割できなかった例だと思う
引数が省略されることで「全く別」の動作をしてしまう

カレントブランチの変更はコマンドとして独立させて別名を与えるべきだった
〇〇のチェックアウトが「〇〇ブランチへの移動」だなんて冷静に考えてやっぱり変だろう

757 ：デフォルトの名無しさん：2011/05/16(月) 07:03:23.79

GitHub will switch to English-only on Friday, May 20, 2011.
ttps://gist.github.com/a4b4fac18beb08335919

758 ：デフォルトの名無しさん：2011/05/16(月) 07:42:37.85

>>756
1リポジトリに1作業ツリーというのがGitの特徴でもあるからね。
他のVCSみたいにブランチ毎に別ディレクトリにチェックアウトしたりしないから
まずそこで戸惑ってるんでしょ。そこが理解できればgit-checkoutのやり方でも
違和感無いはず。

そもPlumbingのコマンドを複数組み合わせて手間を無くしたのがPorcelainだから、
複数の動作が組み込まれちゃってるのも道理。

759 ：デフォルトの名無しさん：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に置き換わってる？

760 ：デフォルトの名無しさん：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が提供する一番ネットワークに負荷がかからない方法でお願いします。

761 ：忍法帖【Lv=38,xxxPT】：2011/05/17(火) 06:42:28.05

Introducing GitHub Compare View - GitHub
https://github.com/blog/612-introducing-github-compare-view

762 ：デフォルトの名無しさん：2011/05/17(火) 06:52:56.28

>>761
コマンドでは出来ないってことですか？
compareはrawでは無いですよね？

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

http://www.wikivs.com/wiki/GitHub_vs_Gitorious
によれば、raw diffは手に入らないようです。

763 ：デフォルトの名無しさん：2011/05/17(火) 06:57:43.93

>>760
>要はgitが提供する一番ネットワークに負荷がかからない方法でお願いします。
github鯖自体への負荷は問題にしないってか?

764 ：デフォルトの名無しさん：2011/05/17(火) 07:00:31.05

>>763
なぜ別の話になるのですか？

765 ：デフォルトの名無しさん：2011/05/17(火) 07:00:35.51

>>762
>コマンドでは出来ないってことですか？

Git においてリモートリポジトリを操作するという思想はそもそも存在しない。
github.com の compare でどうにもならないのだったらあきらめて fetch しろ。

766 ：デフォルトの名無しさん：2011/05/17(火) 07:10:19.51

>>765
なるほど、「出来ない」のですね。
色々と割り切った考え方の元に作られたツールだと
思ってましたが、そういうのも出来ないのは驚きでした。
使っていたソフトの開発元が svn+trac からgithubに
変わってしまってかなり機能後退と分かりゲンナリです。

普通にDLしてdiffするのが短時間で済みそうなので
これにて。ありがとうございました。

767 ：デフォルトの名無しさん：2011/05/17(火) 07:29:56.81

「分散」型バージョン管理システムなのにリモートリポジトリを操作するって発想がよくわからん

768 ：デフォルトの名無しさん：2011/05/17(火) 07:40:58.12

そろそろ爆釣宣言が来るか?

769 ：デフォルトの名無しさん：2011/05/17(火) 07:44:13.39

github diffでググったら4件目くらいに出てきたよ

770 ：デフォルトの名無しさん：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喰らっちゃったよ。

771 ：忍法帖【Lv=38,xxxPT】：2011/05/17(火) 08:56:07.88

>>770
.patchのほうが生のパッチだよね
.diffのほうはそのままだとpatchには食わせられなかったりする

772 ：デフォルトの名無しさん：2011/05/17(火) 16:57:16.85

git checkoutって変更したファイルは確認でなかっけ？

773 ：デフォルトの名無しさん：2011/05/17(火) 17:14:08.84

わっ確認出ないなあぶねー

774 ：デフォルトの名無しさん：2011/05/17(火) 17:14:59.82

コミット前でreflogにもでないし開発中にやったら悶絶するなこれ

775 ：デフォルトの名無しさん：2011/05/17(火) 17:47:40.52

パス指定したらそりゃ上書きするでしょう…そういうものだもの

776 ：デフォルトの名無しさん：2011/05/17(火) 17:50:27.16

だから git-checkout branch_name は「ブランチ移動コマンド」ではないと何度

777 ：デフォルトの名無しさん：2011/05/17(火) 23:34:48.83

>>760
git clone git://github.com/user/project.git
cd project
git diff v0.1 v0.2

778 ：デフォルトの名無しさん：2011/05/17(火) 23:39:46.40

mjrs ktkr

779 ：デフォルトの名無しさん：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
　　　　　　　　 `、　 │　　　 |
　　　　　　　　ヽ＿｣､＿＿｣
　　　　　　　　　　　　ヽ::::ｌ:::::::::::::|

780 ：デフォルトの名無しさん：2011/05/18(水) 10:51:59.13

>>777
> 要はgitが提供する一番ネットワークに負荷がかからない方法で

と思ったが条件はみたいしてるか

781 ：デフォルトの名無しさん：2011/05/18(水) 12:12:20.78

都度 clone するヤツは頃してもいいとオモ

782 ：デフォルトの名無しさん：2011/05/19(木) 23:20:09.07

TortoiseGitってDebugだと全然ビルド通らない
DebugだとReleaseと全然プロジェクトの設定が違っていたりする
気づかずに放置するということは、ろくにデバッグをしていないということか

783 ：デフォルトの名無しさん：2011/05/20(金) 00:14:43.88

リリース用じゃないんだろ

784 ：忍法帖【Lv=9,xxxP】：2011/05/20(金) 02:46:09.63

Gitは、スゲーむずかしいから、分散VCS初心者は
もっとわかりやすいのをやったほうがいい。

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

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

普通のSIerとかだと、むりだわ。

785 ：デフォルトの名無しさん：2011/05/20(金) 08:42:57.02

SIerって。。。

786 ：デフォルトの名無しさん：2011/05/20(金) 08:44:24.94

gitの難しさは既存のバージョン管理と管理方法がかなり離れていることが大きい
ステーシングの扱いとか、したいことに対してコマンド名があっていないとかも混乱の元
ただこれらは、Bazaar Explorerのようなバカチョンツールである程度解決できる

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

それとgitに限らないができることが多すぎるのでgit flowのような決まったワークフローを強制するツールがあると
使う方は楽なんだよね

787 ：デフォルトの名無しさん：2011/05/20(金) 08:46:51.46

最近オブジェクトレベル(いわゆる低レ)操作スクリプトに凝っている俺が来ますたよ。

788 ：デフォルトの名無しさん：2011/05/20(金) 09:15:49.57

Linusの個人ツールに使いやすさ、分かりやすさを求めるのが間違いです

789 ：デフォルトの名無しさん：2011/05/20(金) 09:41:44.30

プログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
プログラム作ったことのない人にはまあ無理だ
見たことも聞いたこともないものを取り扱うソフトなんて使いこなせるはずがない

今後使いやすくなるとしても、プログラマ的使い勝手の良さが優先されることだろう
…まあ、別に苦行者じゃないので、gitg みたいなのは誰でも歓迎ではあるだろうけど

790 ：デフォルトの名無しさん：2011/05/20(金) 09:41:58.76

>>788
もうLinusは開発に関わってないんだがｗｗ

791 ：デフォルトの名無しさん：2011/05/20(金) 09:56:10.51

メンテナはしてないけどパッチはたまに送ってるよ

792 ：デフォルトの名無しさん：2011/05/20(金) 12:29:25.68

>>789
x プログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな
o Unixプログラマならまあこれでもわかるだろう、というポリシーのもとに制作されてるからな

793 ：414：2011/05/20(金) 13:39:30.82

>>790
http://bit.ly/m4BEAV

794 ：790：2011/05/20(金) 14:00:55.30

>>793
指摘感謝
ともあれ今やこの程度のコミット頻度であっても
「プログラマ以外には全くもってわかりにくいように」
というLinusの意思が連綿と生き続けているのは凄いねｗ

>>789
GUIなら分かりやすいんだ、へーｗ

795 ：デフォルトの名無しさん：2011/05/20(金) 15:17:45.62

正直、Gitが分かりにくいということが理解できない。
そんなに不親切かな？　かなりの人が普通にGitHub使ってると思うんだが。

796 ：デフォルトの名無しさん：2011/05/20(金) 15:21:52.27

ユースケースをかいてこの場合はこの手順ってのを一まとめにしてあげたほうがいいんじゃないかな？
いまのところこういうのがまとまってるところ無いしね。

おれみたいなヤツの為にまとめてくれｗ

797 ：デフォルトの名無しさん：2011/05/20(金) 17:18:04.03

>>796
Git での分散作業
http://progit.org/book/ja/ch5-0.html

798 ：デフォルトの名無しさん：2011/05/20(金) 18:25:46.40

Gitを解説したブログとかチートシートがよく話題になってるけど、
あんなんを拾い読みするより、入門Gitを頭からとうして読んだほうが全然いい。
ソースは俺。

799 ：デフォルトの名無しさん：2011/05/20(金) 19:40:37.33

入門Gitを読んだあとはどんな文献を読むと良いでしょうか
gitの基本操作やブランチの操作はばっちりですがいまいちrebaseの辺りが不安です
svnとの連携についても，gitから入ったので既存のバージョン管理ソフトの仕組みが微妙です

800 ：忍法帖【Lv=9,xxxP】：2011/05/20(金) 19:48:44.63

>795

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

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

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

これって、もう Best Practice あるの?

801 ：デフォルトの名無しさん：2011/05/20(金) 20:21:38.12

その、どんなVCSを使おうが炎上しそうな条件設定で、何が語りたいの？

802 ：デフォルトの名無しさん：2011/05/20(金) 20:26:42.18

>>800
http://progit.org/book/ja/ch5-1.html

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

これは、複数リポジトリ型のワークフローのひとつです。
何百人もの開発者が参加するような巨大なプロジェクトで採用されています。
有名どころでは Linux カーネルがこの方式です。
統合マネージャーを何人も用意し、それぞれにリポジトリの特定の部分を担当させます。
彼らは若頭 (lieutenant) と呼ばれます。
そしてすべての若頭をまとめる統合マネージャーが「慈悲深い独裁者 (benevalent dictator)」です。
独裁者のリポジトリが基準リポジトリとなり、すべてのメンバーはこれをプルします。

803 ：デフォルトの名無しさん：2011/05/20(金) 23:24:23.32

>>800
大丈夫だ
Git以外でも炎上する

804 ：デフォルトの名無しさん：2011/05/21(土) 03:20:19.16

commitするときのコメントを日本語にすると何か不都合あるかな？

805 ：デフォルトの名無しさん：2011/05/21(土) 03:35:50.09

大丈夫だ、問題ない

806 ：デフォルトの名無しさん：2011/05/21(土) 10:13:24.83

一番いい文字コードを頼む

807 ：デフォルトの名無しさん：2011/05/21(土) 11:26:34.61

>>806
TRONコード

808 ：デフォルトの名無しさん：2011/05/21(土) 12:08:30.17

>>798
チートシートっていわゆる日本語で言うとカンペだからね。
理解している人がチラ見するものだよねぇ。

809 ：デフォルトの名無しさん：2011/05/21(土) 15:41:35.38

>>808
良いこと言うね。たしかにその通りだ。
いいから早く使わせろ、って態度でやるから「Gitムズカシイ！！！」とか言い出すんだと思う。
自分のソースコードを任せるんだから、あやふやな理解で良いはずがない。

810 ：デフォルトの名無しさん：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できたらありがたいのですが。

811 ：デフォルトの名無しさん：2011/05/22(日) 00:07:54.68

>>809
ローカルで細々とやってる分には
チートシート程度で理解できないツールは不便だがな
svn, cvs みたくサーバー準備が必要なわけでもなし
分散管理なら「はよ使わせろ」と普通に思うわ

812 ：デフォルトの名無しさん：2011/05/22(日) 00:35:10.43

>>811
集中型の思考回路のままで使うのじゃなければ、チートシートでもいけるんじゃないか。
例えばhgに慣れてる人なら。

>>810
mergeコマンドはカレントのブランチにマージするものだから、出来ないね。
てかマージはコンフリクトする可能性があるから、まずチェックアウトしないとその後が困る。
あと
＞git checkout -b master
の -b は要らないと思う。

813 ：デフォルトの名無しさん：2011/05/22(日) 06:32:29.65

低レベル操作によって、ワーキングディレクトリを一切無視して
- index のバックアップ
- master をindexに読んでくる
- マージ試行
- master をすすめる
- index を戻す
ことはできる。もちろん conflict ナシが前提。

俺も、任意のインデクスに対してマージしてくれるコマンドが欲しい。

814 ：デフォルトの名無しさん：2011/05/22(日) 08:53:46.35

>>812
それ「分かってるヤツがチートシートを読めば分かる」と言ってるだろw

815 ：デフォルトの名無しさん：2011/05/22(日) 13:03:37.20

>>812
>mergeコマンドはカレントのブランチにマージするものだから、出来ないね。
まあそうですね。
ありがとうございました。

816 ：デフォルトの名無しさん：2011/05/22(日) 13:07:27.32

>>814
例えばGit初めてでもhgに慣れ親しんでる人とCVS一本槍の人じゃ、チートシートの効果が全然違うでしょ

817 ：デフォルトの名無しさん：2011/05/22(日) 13:15:08.94

hg glog (graph log) に相当するのは、gitでは何でしたっけ？gitkとかはなしで。

818 ：デフォルトの名無しさん：2011/05/22(日) 13:26:07.45

>>756
>カレントブランチの変更はコマンドとして独立させて別名を与えるべきだった
>〇〇のチェックアウトが「〇〇ブランチへの移動」だなんて冷静に考えてやっぱり変だろう

同意。git swtich ブランチ名にしてほしかった。

819 ：デフォルトの名無しさん：2011/05/22(日) 13:40:18.45

>>817
hg glogがどういうものかわからんけどgit log --graph --decorateでどう？

820 ：デフォルトの名無しさん：2011/05/22(日) 14:19:05.40

俺は[alias]にsw = checkout というむちゃなエイリアスしてる。

821 ：デフォルトの名無しさん：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であることを調べるには？

822 ：デフォルトの名無しさん：2011/05/22(日) 14:26:35.49

>>813
ちょっとやってみたよ。環境変数で別にインデックスファイルを指定してみた。
http://d.hatena.ne.jp/unpush/20110522/1306041303
コンフリクトした時が問題だけど、低レベルコマンドで出来るね。

ただ、チェックアウトしないでマージするのって、普通はそんなに必要にならないような
気がするんだけど、どういう場面でやるんだろ？
現時点でmasterに戻せるか＆軽く動作確認とかだとやっぱチェックアウトしないと
と思うんだけどな。

823 ：デフォルトの名無しさん：2011/05/22(日) 16:08:46.16

>>821
それ無いんだよねたぶん。。。ある意味必要かもしれないと思う。
hgにはあったりするのかな？
いちおう、git show-branch でそれっぽい事が分かるよ。

824 ：デフォルトの名無しさん：2011/05/22(日) 17:45:16.50

それっぽいというか、まさにその為のコマンドだけどな。

825 ：デフォルトの名無しさん：2011/05/22(日) 19:09:42.70

hgと同じってこと？

826 ：デフォルトの名無しさん：2011/05/22(日) 22:41:24.23

>>808
上手いこというな
自分でひと通り試した後カンペ(チートシート)を書くと覚えやすいし
後で見ても自分の言葉なので思い出しやすい
自分のためのチートシート書くのは本当にオススメ

827 ：デフォルトの名無しさん：2011/05/22(日) 22:42:50.22

質問です。

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

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

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

これがいちいち面倒なので、
Gitの機能でうまいことできるのかどうか教えていただけませんか?
別のGitリポジトリから
特定のコミットだけ引っ張ってくる
といったことが出来れば
それを使えるのかとは思うのですが。

828 ：デフォルトの名無しさん：2011/05/22(日) 22:49:04.49

>>827
hgのtransplant拡張なら可能

829 ：デフォルトの名無しさん：2011/05/23(月) 00:41:01.59

>>827
git-svnとcherry-pickでいけるんじゃないかな。

あとGit的には２つのsvnリポジトリが同じになったタイミングでマージして起点を作っといたら
良い感じになりそうなものだけど、svnに戻すことを考えると、そうもいかないんだよなぁ。

830 ：デフォルトの名無しさん：2011/05/23(月) 07:15:41.62

git-cherry は童貞クンを探すコマンドで
git-cherry-pick はおねいさんが童貞クンを妻み喰いするコマンドですよね?

831 ：デフォルトの名無しさん：2011/05/23(月) 07:30:00.89

>>830

832 ：デフォルトの名無しさん：2011/05/23(月) 11:22:23.58

>>821
git branch -vv

833 ：デフォルトの名無しさん：2011/05/23(月) 22:33:08.13

>>810

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

＞## マスターブランチに戻ってマージ
＞git checkout -b master
＞git merge --no-ff dev-xxx

834 ：デフォルトの名無しさん：2011/05/24(火) 02:41:46.09

>>795
あのオプション群が腐ってないと思ってる方が理解できない

835 ：デフォルトの名無しさん：2011/06/01(水) 22:01:57.56

git-svnしたレポに対し、 rXXXXXX みたいなタグを10マンコ生成してみたけどいろいろ糞遅いよ? 死ぬの?
git-pack-refsが焼け石に水みたいな感じ。

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

でも git log --decorate --oneline とか git describe が便利になるんだよな。まんこまんこ。

836 ：デフォルトの名無しさん：2011/06/01(水) 22:55:50.86

>>835

837 ：デフォルトの名無しさん：2011/06/01(水) 23:34:39.51

>>835

838 ：デフォルトの名無しさん：2011/06/01(水) 23:41:35.68

>>835

839 ：デフォルトの名無しさん：2011/06/02(木) 05:55:01.04

あるコミットからあるコミットまでの間に　変更のあったファイル
のリストが欲しいのですが、
Gitではどのようにすれば表示させられますか?
ひとつのコミットについては、
git log --stat
で表示させられたのですが。。。

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

すみませんが
もし分かる方がいらっしゃったらよろしくお願いします。

840 ：デフォルトの名無しさん：2011/06/02(木) 06:42:10.18

まずは git diff --stat a^..b から試せ。
ちなみに git log --stat というのもできる。

841 ：デフォルトの名無しさん：2011/06/02(木) 17:15:59.62

Diffでもstat使えるんですね
試してみます

842 ：デフォルトの名無しさん：2011/06/02(木) 17:40:13.98

github落ちてね？

843 ：デフォルトの名無しさん：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.
いちおうオフィシャルに認識した出来事ではあった模様

844 ：デフォルトの名無しさん：2011/06/02(木) 18:41:40.08

.macとはえらい違いだな
あっちは障害があったことを
まったく認識しとらんからな

845 ：デフォルトの名無しさん：2011/06/02(木) 20:38:05.17

まんこまんこ

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

出典「なんでもおまんこ」谷川某

846 ：デフォルトの名無しさん：2011/06/02(木) 20:39:01.34

>>845

847 ：デフォルトの名無しさん：2011/06/02(木) 22:59:48.23

滑ってる

848 ：デフォルトの名無しさん：2011/06/03(金) 21:31:11.95

まんこまんこおっさんはどこ?

849 ：デフォルトの名無しさん：2011/06/04(土) 18:43:12.63

Cygwin の Gitを使用しているのですが、EclipseやNetBeansで作成したファイルをcomittすると
create mode 100755 .classpath
みたいになってしまいます。
(UTF-8の場合？)

デフォルトで644にしたいのですが、どういう設定を行えばよいでしょうか？

850 ：デフォルトの名無しさん：2011/06/04(土) 18:53:23.00

"git core.filemode"でググれ

851 ：デフォルトの名無しさん：2011/06/04(土) 19:19:28.82

>>850
その設定はfalseにしているのですが、初回コミット時に755になってしまうのです…

852 ：デフォルトの名無しさん：2011/06/04(土) 20:26:23.63

まんこまんこだけど、そこそこ安定している msysgit-1.7.5 のありかきぼん。
ぐぐって見つけた版はなんかヘンだった。

gitdir 拡張が使いたいので 1.7.5 以降じゃないと具合悪いんだ。

853 ：デフォルトの名無しさん：2011/06/04(土) 20:32:04.20

そういやmsysgitの公式バイナリはまだ1.7.4なんだな
いつもながらの遅さだわｗ

854 ：デフォルトの名無しさん：2011/06/04(土) 20:36:16.44

homebrew する必要があるかw
公式つーても永遠の preview か?

多量タグ対策(あえて略すがまんこ対策)もしないといけないから、この際自前で作るか。

855 ：デフォルトの名無しさん：2011/06/05(日) 07:37:02.38

TDDのときにGitを使う上での便利な使い方とかありますか？

856 ：デフォルトの名無しさん：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/

857 ：デフォルトの名無しさん：2011/06/05(日) 21:24:23.86

フックスクリプトとかそういう話を期待してんじゃね？

858 ：忍法帖【Lv=6,xxxP】：2011/06/08(水) 14:24:10.18

おまえら、ちょっと教えてくださりませんか。

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

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

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

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

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

いまの俺の解は、設定ファイルがぶっこわれたら、
git管理外の自分の設定ファイルをコピってくる。
だが、もうちょっとなんとかならんか。

859 ：デフォルトの名無しさん：2011/06/08(水) 14:31:26.04

> なぜか、このプロジェクトのきまりで設定ファイルをignoreに入れることができない。
管理者になったなら管理者権限でこのルール変えちまえｗ

860 ：デフォルトの名無しさん：2011/06/08(水) 23:02:38.84

>>858
プログラマ別に固有のリポジトリ/リモートブランチ持たせて>>858がmasterにマージすれば？
ignoreできないのもアホすぎるけど、各プログラマが自分で判断してマージする能力を持ち合わせてないように見える。

861 ：デフォルトの名無しさん：2011/06/09(木) 03:30:08.08

別人だけどついでに質問させてもらっても良いかな？

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

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

自分用に更新したファイルをコミットせずにおいておくと枝分けたり移動したりするとき邪魔だし
コミットしてしまうと間違えてpushしてしまわないかmergeする度気にしないといけないしで。
たまーに設定項目増えたりするのでexcludeで指定するのも問題あるかなあ、と。

862 ：デフォルトの名無しさん：2011/06/09(木) 04:50:08.35

>>861
雛形のファイル(例えば config.yml.sample)を管理対象にして、
ローカルでは雛形をコピーかつ編集したもの(例えば config.yml)を使う、
という感じ？

863 ：デフォルトの名無しさん：2011/06/09(木) 06:55:00.49

Git使ってて必要のない変更までコミットしてしまうってのが
まずわからん

特に確認せずに、
いつもすべてコミットしちゃってる人ばかりなのか？

864 ：デフォルトの名無しさん：2011/06/09(木) 07:41:58.62

yes

865 ：デフォルトの名無しさん：2011/06/09(木) 10:13:10.50

ディレクトリごとコミットしてしまう人は、他のシステムでは稀に見る
gitでそれを毎回するにはどうやればいいのかまでは知らない

866 ：デフォルトの名無しさん：2011/06/09(木) 11:52:36.35

gitだろうが何だろうが、余計な変更があったら邪魔なのには変わりないと思うが。

867 ：858 忍法帖【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の両方でリポジトリを共用できますなんて、言わなきゃよかった。
# 雉も鳴かずば撃たれまいに。

868 ：デフォルトの名無しさん：2011/06/09(木) 18:44:44.47

自分で覚えようとしない人に覚えさせるってのはだいたいうまくいかない

869 ：デフォルトの名無しさん：2011/06/09(木) 23:45:14.56

自分で覚えようとしない人はこの業界自体あれだよな…

870 ：デフォルトの名無しさん：2011/06/10(金) 00:19:08.60

>>862
ああ、確かにそうするのが適切かもしれませんね。
sampleファイルの名称変更はビルドとかデプロイとかの中で行うわけですね。

871 ：デフォルトの名無しさん：2011/06/10(金) 00:24:38.04

というかgit ignore禁止に理由が知りたい

872 ：デフォルトの名無しさん：2011/06/10(金) 01:25:37.34

>>871
そんな設定して誤爆したら困るじゃないか
責任取れるのか？

873 ：忍法帖【Lv=7,xxxP】：2011/06/10(金) 01:41:28.21

>866
プログラマーがすべて、866みたいに注意深い人間なら、
デスマももうすこし減ってもいいはず。

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

いきなり開発環境でやるなって話だけど、まあ cloneはおまじない
init は教えてないから、こっちが悪いってのもあるか....l

874 ：忍法帖【Lv=7,xxxP】：2011/06/10(金) 01:48:53.32

>868
それは、そのとおりなんだが。gitを知らない人も、
オレも生き残りたい。

>871
おれも知りたい。

hogefuga.yml.sample とかつくって, hogefuga.ymlをgit rmして
再スタートできたらなあ。プロジェクトの最初からそうしてくれて
いたら.... ってグチってもなんとかならんな。

875 ：デフォルトの名無しさん：2011/06/10(金) 01:59:28.88

git commit -a したところで untracked なファイルはコミットに含まれないはずだけど。

876 ：デフォルトの名無しさん：2011/06/10(金) 02:03:08.14

・そうしないと管理工数が増えて実開発時間が減ります
・リリース時にミスって顧客に迷惑かけるリスクが増えます
とかってプロマネの立場にたった抗弁でルールを変えてもらったほうがいい

877 ：デフォルトの名無しさん：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
...

結構色々あるな…

878 ：デフォルトの名無しさん：2011/06/10(金) 02:33:39.98

>>872
例えばどんな誤爆？

879 ：デフォルトの名無しさん：2011/06/10(金) 08:32:43.27

手をかけようとするのをやめな
事故を起こさせて困らせてから、それを解決しろ
どうせ誰も衝突や消失や手戻りの手痛い経験がないんだろ
なんのために存在するか理解できていないものは、「おまじない」になって永遠に理解されない

880 ：デフォルトの名無しさん：2011/06/10(金) 09:21:49.29

活発なオープンソースプロジェクトを独自変更で追いかけて行く（もちろんこっちの変更は取り込まれない）
てのを実際にやったら、ほとんどの上位コマンドとGitの仕組みが理解出来ると思うな。
ついでに並行してsvnで同じ事やらせたら分散型の有用性も実感できる。

881 ：デフォルトの名無しさん：2011/06/12(日) 01:30:01.95

Windows上で、Eclipseで作ったjavaファイルをCygwin Git で管理し始めました。

> create mode 100755 xxxx.java
となるのが気持ち悪いのですが、皆さんはどうされているのでしょう？
逐一chmodしているのでしょうか、それとも放置？

882 ：デフォルトの名無しさん：2011/06/12(日) 05:29:17.11

>>881
/etc/fstabにnoacl,notexecでどうだろう
どんな副作用が出るかは知らない

883 ：デフォルトの名無しさん：2011/06/12(日) 10:01:54.08

一般公開部分と非公開部分があるプロダクトを扱うことになったんだけど、
・リポジトリAには公開部分を置いて一般公開
・リポジトリBには非公開部分を置いて適当な認証を入れてアクセス限定
という運用はgitでできるでしょうか？

884 ：デフォルトの名無しさん：2011/06/12(日) 12:10:44.39

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

でいいんではないか? さしあたっては A をGithubなどで運用するケースを考えてみるとよい。

885 ：デフォルトの名無しさん：2011/06/12(日) 12:55:11.58

tarballでのリリースでなくてリポジトリの公開か。
コミットログにも注意しないとなｗ

886 ：デフォルトの名無しさん：2011/06/12(日) 20:06:36.25

>>883
プロダクト毎にリポジトリを分けようとすると混乱する。
リポジトリは公開/非公開で分けて、パッケージングは別にすればいい。

887 ：デフォルトの名無しさん：2011/06/12(日) 23:52:37.48

>>884-886
回答どうもです

大元は同じコードなので、公開用と非公開用でブランチを割って
それぞれリポジトリA、Bみたいな感じでいけそうかな、と思います

888 ：デフォルトの名無しさん：2011/06/13(月) 01:14:47.45

>>882
ありがとうございます！
その単語でググったら色々情報ヒットしましたので参考にします。

889 ：デフォルトの名無しさん：2011/06/15(水) 12:22:11.41

まんこまんこだけど、まんこ(aka 100k refs)の話題をMLに投げてみたら、意外な方向に話が脱線してる。

要約「git notesの逆引きを充実させよう」

890 ：デフォルトの名無しさん：2011/06/16(木) 21:37:28.88

会社でcvs使ってるんですけど、
リポジトリをsubversionに変換して（他のメンバー向け）、
（自分だけ）git-svnかますのって実用的でしょうか

891 ：デフォルトの名無しさん：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

892 ：デフォルトの名無しさん：2011/06/16(木) 23:31:54.16

>>891
あなたが原因だと思う

893 ：891：2011/06/17(金) 07:18:00.57

もっと具体的にお願いします！

894 ：デフォルトの名無しさん：2011/06/17(金) 17:28:41.97

gitもこういうユーザが増えてきたってことか？

895 ：デフォルトの名無しさん：2011/06/17(金) 17:47:34.45

>>893
バージョン管理システム自体を使うのが初めて？

896 ：デフォルトの名無しさん：2011/06/17(金) 21:57:06.07

ヒント: hint

897 ：デフォルトの名無しさん：2011/06/17(金) 22:22:18.04

エラー：3036a55戻すことができませんでした... 3
ヒント：競合を解決した後、訂正後のパスをマーク
ヒント："RM<paths>をgitの'追加<paths>をgitの'かで
ヒント：ととの結果をコミットするには、"コミットgitの"

898 ：デフォルトの名無しさん：2011/06/17(金) 23:58:23.63

お祭り会場
https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac

899 ：デフォルトの名無しさん：2011/06/18(土) 01:36:43.20

>>898
All your /usr are belong to us.

900 ：デフォルトの名無しさん：2011/06/18(土) 06:48:11.71

/usr 配下に重要なファイルをインスコするOSは傍流

901 ：デフォルトの名無しさん：2011/06/18(土) 11:38:54.21

>>900
/usr/homeがあるFreeBSDのことか

902 ：デフォルトの名無しさん：2011/06/18(土) 12:53:47.73

>>901
何を言うか、FreeBSDはpackageから/usr/localにインスコするではないか

903 ：デフォルトの名無しさん：2011/06/18(土) 12:54:21.53

…あれ、なんかすごいボケてたので↑はなしでｗ

904 ：デフォルトの名無しさん：2011/06/18(土) 19:56:59.66

>>895
初めてです

905 ：デフォルトの名無しさん：2011/06/20(月) 08:37:35.99

>>904
そうですか
それではまず服を脱ぎます

906 ：デフォルトの名無しさん：2011/06/22(水) 18:32:18.48

入門Gitを斜め読みしています。(←難しくてぜんぶは理解できない...)

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

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

そのようにしないと、
マージコミット
(これはどこそこブランチからマージされましたとかいうログだけのコミット)
ができてしまって気持ち悪いなあと思っていたのですが...

907 ：デフォルトの名無しさん：2011/06/22(水) 20:38:59.46

>>906
私も勉強中なので間違ってるかもしれませんが...

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

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

自分は
> (これはどこそこブランチからマージされましたとかいうログだけのコミット)
> ができてしまって気持ち悪い
の場合にはmerge --no-commit でマージした後、手動でコミットしています。

908 ：デフォルトの名無しさん：2011/06/22(水) 21:03:03.14

>>906
何ページだったか忘れたけど、マージコミットを嫌うやり方もある一方で
どんどんマージするやり方もある、て書いてあるよ。
つまりrebaseしないのはバカって訳ではない。
例えばバグ修正してるのに余計なコミットを混ぜ混んでったらダメだ、ってことだよね。

909 ：デフォルトの名無しさん：2011/06/22(水) 21:09:05.44

tortoisegitのtgitcache.exeのバグは治った？
ファイルハンドル？取りっぱなしになっちゃうやつ

910 ：デフォルトの名無しさん：2011/06/22(水) 22:42:56.90

>>909
XP上のTortoiseGitで、ログウィンドウとかを閉じようとしてもなかなか閉じず、
やっと閉じたと思ったらTortoiseProc.exeが残ったままになるんだけど
同じバグかな？

911 ：デフォルトの名無しさん：2011/06/23(木) 05:42:15.67

GitHub for Mac
http://mac.github.com/

912 ：デフォルトの名無しさん：2011/06/23(木) 06:24:27.56

906です。
レスありがとうございました！
のちほど本と照らし合わせながら
きちんとレスを読ませていただきます！

913 ：デフォルトの名無しさん：2011/06/23(木) 14:32:56.76

>>911
これどの層に需要あんの？

914 ：デフォルトの名無しさん：2011/06/23(木) 14:36:49.76

>>913
まあ、ないよな
Macなんて誰も使ってないし

915 ：デフォルトの名無しさん：2011/06/23(木) 14:41:47.29

>>914
おい俺はMac使ってるぞ

でも>>911の利用価値はサッパリわからんぞ

916 ：デフォルトの名無しさん：2011/06/23(木) 14:58:29.46

Tower(これもGitクライアントアプリ)に興味を持つ人なら
>>911も試すんじゃないかな？
俺は試した。そっと終了したが。

917 ：デフォルトの名無しさん：2011/06/23(木) 14:59:58.09

そんなにダメなのか

918 ：デフォルトの名無しさん：2011/06/23(木) 15:10:26.28

Towerといい…なんでMacのGitアプリはCPU使用率がこんなに高いんだろう
HitoryをスクロールするだけでCPU100%越えるんだが

919 ：デフォルトの名無しさん：2011/06/23(木) 18:08:07.34

>>918
新しい Mac を買えってことだよ。

920 ：デフォルトの名無しさん：2011/06/23(木) 19:42:36.62

>>919
去年買ったモデルでも一緒です

921 ：デフォルトの名無しさん：2011/06/23(木) 19:52:52.41

まんこ詩んだ？

922 ：デフォルトの名無しさん：2011/06/23(木) 22:15:05.17

>>918
Macが重いのはPowerPC時代からの伝統だよ

923 ：デフォルトの名無しさん：2011/06/23(木) 23:28:40.30

2chの人たちはMac派は少ないのか？。。。
私がフォローしているTwitter上の人たちや勉強会に参加してる人たちは
Macが多いけど。。。

924 ：デフォルトの名無しさん：2011/06/24(金) 00:08:06.86

俺一応使ってるよ。
UTF-8-MACだったりとかファイルシステムが大文字小文字区別出来なかったりとか
いろいろ難点あるけどね…

925 ：デフォルトの名無しさん：2011/06/24(金) 00:11:30.62

以前HFS+(Macのファイルシステム)でケースを区別するようにフォーマットし直したら、
市販ゲームの一部に動かなくなるもの(Civlization IV)があって断念した。
ゲームプログラム内の文字列部分を覗いたら、ファイルパスが全部大文字で
格納してあって、呆然としたわ。

926 ：デフォルトの名無しさん：2011/06/24(金) 00:38:08.12

>>923
Macは使ったことあるけど、自分の用途ではLinuxのほうが速いし楽だし便利だし
という結論になった

927 ：デフォルトの名無しさん：2011/06/24(金) 01:30:07.96

勉強会に出てるような人らって
UNIX系OSのノートPCとして使いたいから
WINじゃなくMac選んでるイメージ。

928 ：デフォルトの名無しさん：2011/06/24(金) 02:22:13.40

そういえばおととしぐらいにOSSカンファレンス行ったら
会場の7割ぐらいがノートでメモとってて、さらにそのうち9割ぐらいがMacだったな。
ステッカーベタベタ貼ってるようなヤツも居た。

929 ：デフォルトの名無しさん：2011/06/24(金) 07:08:58.54

twitter使いは猿が多いからどうしてもMac使いが多くなる

930 ：デフォルトの名無しさん：2011/06/24(金) 07:29:56.35

Webやってる連中はOSXが便利だな。つかWindowsがダメすぎ。

931 ：デフォルトの名無しさん：2011/06/24(金) 13:44:23.91

ＵｂｎｔやＣｅｎｔじゃだめなんかい？

932 ：デフォルトの名無しさん：2011/06/25(土) 00:26:21.59

プライベートならSUSEが安定してていいな

仕事WinXP、自宅SUSE Linuxだった所に
最近業務のサブノートでMac Air使い始めたが
Win, SUSEより使い勝手悪くてワロタ

933 ：デフォルトの名無しさん：2011/06/25(土) 02:54:23.13

>>932
SUSEとやらは聞いたことがなかったな
他のlinuxディストリと比べて何が違うの？git方面で

934 ：デフォルトの名無しさん：2011/06/25(土) 12:01:19.35

>>933
統合環境としてのSUSEが便利なのであって、
gitというツールに着目したら他Linuxと大して変わらんぞ

935 ：デフォルトの名無しさん：2011/06/25(土) 13:38:37.20

githubとか(自分で作ったものでもそうだと思いますが)、リモートのリポジトリに対して
git gc に相当することはできないのでしょうか？

リモートのブランチを削除したのですが、webブラウザからURLを直接指定すると
相変わらずそのブランチのコミットが参照できるのが気になりまして…

936 ：デフォルトの名無しさん：2011/06/25(土) 15:26:52.73

しばし待て。もしかして活動履歴から当該ブランチのハッシュが消え失せるまでプルーンされなかったりしてな!

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

余談。他プロジェクトのフォークではない大きなプロジェクトをプッシュしてたら無料分のソフトリミット超えちゃった。
圧縮される気配がないので、手元でrepack, Githubプロジェクトを削除・再作成, packされたオブジェクトをpush
したら、目論見通りGithubのプロジェクトを圧縮状態にできた。
もうすこしおかねもちになったら、こんなみみっちいことをせず課金拡張しよう。

937 ：デフォルトの名無しさん：2011/06/25(土) 22:31:40.75

TortoiseGitって細かいバグが多くて嫌だわ
TortoiseSVNとかTortoiseHgはもっと安定しているというのに

938 ：デフォルトの名無しさん：2011/06/26(日) 00:47:32.69

>>937
バージョンは？

939 ：デフォルトの名無しさん：2011/06/26(日) 01:45:57.08

>937
TortoiseBzrも忘れないでくださいね

940 ：デフォルトの名無しさん：2011/06/26(日) 20:20:31.27

亀gitはバグ対応速度も亀並みなんやな・・・

941 ：デフォルトの名無しさん：2011/06/26(日) 20:24:00.39

日本語混じりのコミット(と、ログ)以外、コマンドラインで十分な体に飼いならされちゃったわい。
tgitcache.exe とかいう有害なプロセスは都度Killしてるよ。

942 ：937：2011/06/27(月) 12:37:17.98

Nightly build(1.7.0.0)を試してみたけど、バグは直るどころかひどくなった？
以前のバグが直らず放置されているのも多い
覚えているだけでも以下のバグが

・cherry-pickのとき、間違ったupstreamで表示される
・ログを検索したあと、検索を解除しようとしても戻らない
・cherry-pick(rebase)、ログで固まる
・ログ表示などで落ちる
・複数コミットのcherry-pickで、途中のが失敗していても続行
・cherry-pick(rebase)の後間違ったコミットにresetする
・>>941 TortoiseProc.exeもよく残っていて有害
・TGitCache.exeはよくファイルをロックしたまま離さないので、Status Cacheはオフにしたまま
・変更されたファイルを表示しようとすると、少ないファイル数でも何時まで経っても終わらないことが
・TortoiseMergeが競合している行を表示しない
・ベアリポジトリでは使えない？（エクスプローラーでコンテキストメニューが表示されない）

一体どんな設計しているんだ！！

943 ：デフォルトの名無しさん：2011/06/27(月) 12:39:04.75

tortoiseproc.exe は勝手に死んでくれるからまだマシw
(うざいダイアログ粒すのがメンドくさいけどな)

944 ：デフォルトの名無しさん：2011/06/27(月) 14:08:11.78

わざわざ不安定版を探して文句付けてるサディストがいると聞いて

945 ：デフォルトの名無しさん：2011/06/27(月) 23:14:01.16

ナイトリーにいちゃもんつけるとは
一体どんな神経しているんだww

946 ：デフォルトの名無しさん：2011/06/28(火) 03:00:26.89

942じゃないが、いちゃもんつけちゃダメっていうなら何のためにナイトリービルド公開してるの？

947 ：デフォルトの名無しさん：2011/06/28(火) 03:07:56.86

ここでバグ報告してどうする

948 ：942：2011/06/28(火) 03:12:10.44

>>944-945
ここで指摘してやらないと>>942に書いたレベルでリリースされかねないだろうが？
これまでのバージョン見る限りマジやりかねんわ

949 ：デフォルトの名無しさん：2011/06/28(火) 04:50:11.49

ここでバグ報告してどうする

950 ：デフォルトの名無しさん：2011/06/28(火) 07:57:17.66

英語書けないんだよ糞が

951 ：デフォルトの名無しさん：2011/06/28(火) 11:17:10.58

英晤じゃ無きゃダメなんて書いてないだろ
堂々と日本語で書いてスルーされてこいよ

952 ：デフォルトの名無しさん：2011/06/28(火) 12:09:51.63

中国語で書かれたBugzilla PRがフルボッコ(ただし同胞のフォローがすこし)ってのを見たことがある。

953 ：デフォルトの名無しさん：2011/06/28(火) 22:49:42.76

>>942が日本語でも英語でもいいからBugzlllaにチケット挙げないかな
いずれでもフルボッコにされそうで観戦してみたい

954 ：デフォルトの名無しさん：2011/06/29(水) 06:08:48.57

性格ねじ曲がった団塊みたいな意見ですね

955 ：デフォルトの名無しさん：2011/06/29(水) 16:08:16.27

そうだね、セールスの電話で遊ぶクソジジイっぽいよね

956 ：デフォルトの名無しさん：2011/06/29(水) 18:17:58.17

あれだけはマジで基地外じみている...

957 ：デフォルトの名無しさん：2011/06/30(木) 22:13:46.91

eclipse のオマケの EGit はどのように使うのでしょうか。
USB メモリにある小説も管理できますか？

958 ：デフォルトの名無しさん：2011/06/30(木) 22:16:31.09

俺の肛門も管理されています

959 ：デフォルトの名無しさん：2011/06/30(木) 23:05:19.69

なんでわざわざEclipseのEGit使って小説管理するんだ
素直にmsysGit使うえお

960 ：デフォルトの名無しさん：2011/07/02(土) 00:39:35.01

参考までに
http://kokucheese.com/event/index/13468/

961 ：デフォルトの名無しさん：2011/07/02(土) 01:02:24.41

肛門集会と思ってうrl開いたのに…俺の肛門は閉鎖されちゃったよ。

962 ：デフォルトの名無しさん：2011/07/02(土) 20:44:05.63

version 1.7.6 はいかがでしょうか

963 ：天使 ◆uL5esZLBSE ：2011/07/03(日) 15:07:23.76

>>960
ハアァアァアァアァアァァァアァァァァァァァァァァァァァァァァア？？？？？？
気持ち悪い？
あ

964 ：デフォルトの名無しさん：2011/07/03(日) 18:33:25.53

天使さん戻っておいでよ

965 ：デフォルトの名無しさん：2011/07/05(火) 18:24:39.02

make test でエラーが出てしまったわい
それでも入れちゃうけど

966 ：デフォルトの名無しさん：2011/07/06(水) 05:03:26.65

967 ：デフォルトの名無しさん：2011/07/06(水) 05:08:56.07

git status

968 ：デフォルトの名無しさん：2011/07/06(水) 12:14:46.86

git log

969 ：デフォルトの名無しさん：2011/07/06(水) 12:55:35.79

git diff

970 ：デフォルトの名無しさん：2011/07/06(水) 17:25:59.91

git commit

971 ：デフォルトの名無しさん：2011/07/06(水) 18:19:26.29

git rev-parse --git-dir | xargs rm -rf

972 ：デフォルトの名無しさん：2011/07/06(水) 18:27:03.83

おいやめろｗ

973 ：デフォルトの名無しさん：2011/07/06(水) 18:43:40.66

こまめに別のメディアへのバックアップをしましょうね

974 ：デフォルトの名無しさん：2011/07/06(水) 18:44:37.00

git clone --mirror

975 ：デフォルトの名無しさん：2011/07/07(木) 04:02:38.42

git revert

976 ：デフォルトの名無しさん：2011/07/07(木) 09:04:08.90

git rerere

977 ：デフォルトの名無しさん：2011/07/07(木) 10:08:15.83

git odekakedesuka

978 ：デフォルトの名無しさん：2011/07/07(木) 14:07:54.86

rerereはこのまえちょっと便利に感じた。

979 ：デフォルトの名無しさん：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１を別々にコミットするとう方法を行ってます。

これはすごく面倒なので、もっと簡単な方法は無いでしょうか？
複雑に混ざりあった変更から、コミットしたい変更だけ抽出して、任意に個別に（もしくはグループで）コミットする方法あったら教えてほしいです。

980 ：デフォルトの名無しさん：2011/07/08(金) 08:04:18.44

git add -p
で、
まとまりのある変更点だけ選択(抽出)→ステージング→コミット
を繰り返せば良いと思います。

981 ：デフォルトの名無しさん：2011/07/08(金) 14:16:34.72

そういう事態はgit add -i 使ってる

といってもあくまでうっかりのときだな
gitらしくちょっとした作業ごとに細かくブランチを切るようにしたら、いくつものコミットに分ける自体になりにくいよ

982 ：デフォルトの名無しさん：2011/07/08(金) 14:32:26.43

>>881
modeを無視するgit configの設定があったはず
filemodeだったか

983 ：デフォルトの名無しさん：2011/07/08(金) 18:16:44.69

git stash も悪くないよ。

984 ：デフォルトの名無しさん：2011/07/08(金) 19:09:04.90

git add -iの存在を忘れていたなあ。
-pしか使ってなかった。

985 ：デフォルトの名無しさん：2011/07/08(金) 19:35:45.94

>>982
その設定も行っているのですが、初回add時の属性は
ファイルシステムが認識しているものになるようです。