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/

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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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 :172010/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.
>

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が一だが

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

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

29 :252010/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しようとしたら落ちる？それともした結果のもの？

65 :312010/09/26(日) 18:12:35

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

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

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

35 :332010/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

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ハッシュの脆弱性が考えられるから。

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

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

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

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

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

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

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

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

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

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

>>47
正に杞憂

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

>>47
はははｗ

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

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

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

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

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

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

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

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

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

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

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

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

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 環境変数で時間なら操作できます

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

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

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に限らず、普通にハッシュが衝突したってだけでそれなりの話題になるのは必至だろうな

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

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

http://www.mail-archive.com/msysgit@googlegroups.com/msg00745.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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の秘密鍵生成には確率的素数判定法を使っているはず:-)

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

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

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

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

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

>>93
絶対に許さない

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

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

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

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

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

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

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

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推奨はどんなのだろう

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

106 :1022010/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
他人のテストスクリプトに対してそういうケチを付ける気にはならないな、自分は。

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

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

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

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

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

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

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

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

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

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

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でキレイに並べて
おきたい気持ちは分かるんだけど…

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

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

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

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

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

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

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

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

Putty Fatal Error
Network error: Connection timed out

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

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

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

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

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したほうがいいのかなあ。ありがとう。

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と変わらないと思ってたんだけどなあ。

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

>>144
>>135

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

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

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つのコミットになっていた件。
なんなんだこれは…

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使ってる人いますか？
あれ、いつの間にか日本語対応しました？

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の思想によるものなのか、それとも単に分散バージョン管理に慣れていないからなのか、たまに分からなくなる。
特に、分散なんだからそれぐらいできてもよさそうじゃん、ってのができないとき…。

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

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

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

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

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

例えばどういうこと？

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

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

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

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

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

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

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

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

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

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でやった作業なんだか、一見分からない。

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

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

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

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

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した分を飛ばして解決したが他にいい方法合ったのか

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』と言います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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みたいな記法使ったらどうだろ？

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とか出来ちゃう。

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がいいよ

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

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

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

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

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

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

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

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

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 名古屋でググれ。

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

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

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を作成しているのでそのほうがめんどくさいかもしれない・・ですね・・・

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

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

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

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

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

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

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

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が共存するスペースを作れば種々の問題が解決した

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もマカーにかかればこうなるのかｗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 登録名。

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

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

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

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

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

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

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

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

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

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

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

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の扱いがへにょいのと同じ理屈

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

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

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

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

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

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

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

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

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が絡むとカオスが増す

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 :2712010/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したらどうかって。

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

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

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

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

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とかで特定のファイルのみ管理対象にする。。。
みたいなことをしたら邪道といわれましたが、やはり管理したくないファイルを指定したほうがいいのでしょうか？

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する

という風にしてる

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

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

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

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

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

298 :2952010/12/14(火) 22:07:53

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

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

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

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

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

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

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

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

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

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

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

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

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

305 :3012010/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とか？

319 :3042010/12/20(月) 01:03:40

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

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

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

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

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

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

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

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

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

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

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

>>311
だから？

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

Railsは「重い」よ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オレの意見:

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

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

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

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

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

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

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で最初にコミットしたときにはすでにリリースされたものより違うため派生しにくい
・そもそも根本が異なるリポジトリは扱えるのか？

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

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

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

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

でも、今あるmy_repoの履歴も捨てたくないから、この new_my_repo に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で差分は見れるけどそういうことじゃないくて？

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に取り込めばいいわけですし

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

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

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

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

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

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 の日本語化ってできないの

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

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

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

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

362 :3612011/01/11(火) 01:28:21

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

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

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 したい場合の
具体的なワークフローが知りたい

いや教えてください

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

日本語で書いたログメッセージはちゃんと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

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

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

masterがメインで走ってて、安定版をFastForwardでstableブランチにmergeしていってるよくある
リポジトリで、コミットAとCとFとがstableだったってstableの履歴のようなもの知りたいのですが、
何か手はないでしょうか？

383 :デフォルトの名無しさん2011/02/01(火) 21:20:01

>>380
リアルタイムで追いかけて merge とか cherry-pick があったときに tag とか branch でくさび入れるがよろし!

386 :3802011/02/02(水) 09:36:52

具体的にいうとx264のgitリポジトリなんだけどね
masterがどんどん走ってて、ここまでならstable!ってポリシーで行ってるの
はいいけど、１個前２個前のstableをcoしたい。ってのができなくて。
committer が >>383 の言うように "stable:r1875" みたいなtag打ってくれりゃいいんですけどね(´・ω・｀)
どうにもリアルタイムで追いかけてstableなポイントをメモしとかないとダメっぽいですね。
ありがとうございました。

382 :3802011/02/01(火) 17:27:50

それが tag のふられてない既存リポジトリなんですよ
つまりは手はなしってことですか

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 みたいなのがあるんじゃないかと
思って調べても全然見つからないのよね。

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 が変化検出できないっぽい。

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 になっているため、
＃こんなことで悩んでおります。

400 :デフォルトの名無しさん2011/02/09(水) 20:45:18

>>398
その設定だと、コミットログが化け化けで入っていないか？
コンソールでしか作業をしないのなら、ロケールと端末をEUC-JPに変えるという発想は？
LANGだけでロケール変わらないか？

402 :3982011/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で正解のようだ。

409 :3982011/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で試す→うまくいく

399 :デフォルトの名無しさん2011/02/09(水) 19:22:43

aliasで!shとか使えば？

405 :デフォルトの名無しさん2011/02/09(水) 22:00:44

>>402
>>399は
https://git.wiki.kernel.org/index.php/Aliases
でnkf入りのdiffコマンドを作る

406 :3982011/02/09(水) 22:04:50

>>403
読んでみます！
ありがとうございます。

>>405
いろいろ情報ありがとうございます。
そちらも読ませていただきます！

401 :デフォルトの名無しさん2011/02/09(水) 21:12:26

漏れならソースコードをUTF-8にするの一択

404 :3982011/02/09(水) 22:00:16

>>401
> 漏れならソースコードをUTF-8にするの一択

自宅ではそうします！

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等もフィルタすると幸せになれるかもしれない

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

どうして、京都大学霊長類研究所は、アイちゃんの、
スレ乱立を見過ごしてるの？

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

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

糞スレをあちこちにポンポン乱立されちゃ迷惑なんだよ。
ったく、京都大学霊長類研究所は能無しの集まりかよ！

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

426 :デフォルトの名無しさん2011/02/16(水) 12:53:39

>>424
> Gitユーザは、リベースの難しさや、多くのBazaarユーザのやり方に対する非難めいた態度にイライラするかもしれません。 Bazaarでは、コミットは「重たく」、ブランチもとても「重たい」ものです。

425 :デフォルトの名無しさん2011/02/16(水) 11:51:02

うむ、InternalServerError出たからマジで驚いたｗ
リロードしたら直ったけど、This page is obsolete! じゃん！

429 :デフォルトの名無しさん2011/02/16(水) 22:14:04

> Gitユーザは、リベースの難しさ、そしてやり方についての多くのBazaarユーザのとても非難めいた態度に、
イライラするかもしれません。

430 :デフォルトの名無しさん2011/02/19(土) 13:11:26

GITはいつになったら日本語ファイル名に対応するんだ？

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

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

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

怖くて使えねーｗｗｗｗｗ

432 :デフォルトの名無しさん2011/02/19(土) 13:25:42

>>430
Mercurial追い出されて今度はこっちですか？
具体的にどこがどう対応していないのですか？

431 :デフォルトの名無しさん2011/02/19(土) 13:21:19

ユーザの多くがプログラマーなら、そんなもの必要だとは思ってない。

433 :デフォルトの名無しさん2011/02/19(土) 15:17:57

GITでは、WindowsとLinuxの相互運用で日本語ファイル名が文字化けする。

実用に使えない糞ソフト。

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の時代になっても日本人は英語コミュニティに及び腰、だろ?

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
だめだよ、余計なこと教えちゃ

449 :デフォルトの名無しさん2011/02/19(土) 19:26:55

文字化けの話題はもう>>443で解決してる
次の話題どうぞ

450 :デフォルトの名無しさん2011/02/19(土) 19:28:41

>>449はクロスプラットフォームでの問題を理解出来ないバカ。

446 :デフォルトの名無しさん2011/02/19(土) 19:13:36

GITはクロスプラットフォームで文字化けが発生してしまうから使いものにならない。

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

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

どうせファイルとかも消えちゃうんだろ。

447 :デフォルトの名無しさん2011/02/19(土) 19:15:17

>>446
じゃあそれでいいです

はいほかの方どうぞ

448 :デフォルトの名無しさん2011/02/19(土) 19:19:05

うむ、>>446に賛同しておこう
では次の話題に

452 :デフォルトの名無しさん2011/02/19(土) 19:38:53

cygwinを使わないと日本語環境でまともに利用できないバカなソフトがあると聞いて

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()などで
標準出力に出力することすらできない

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
おちつけ

466 :デフォルトの名無しさん2011/02/19(土) 20:17:44.80

>>463
当然ISO-2022-JPも対応しています。cygwinは分からん。

464 :デフォルトの名無しさん2011/02/19(土) 20:08:16.80

開発陣を無能だと思うんなら有能な君がパッチを送ればいいじゃないか

467 :デフォルトの名無しさん2011/02/19(土) 20:22:21.82

Windowsで使えないなんて信じられないニダ！
我が国の母国語が化けるとかクソニダ！
早く使えるようにしろ！！！　謝罪しろ！　賠償しろ！！！

どっかの国の人みたいなこと言ってんなよ、、、

468 :デフォルトの名無しさん2011/02/19(土) 21:37:46.55

単にGITが日本では実用にならない糞ソフトってことだよ。謝罪も賠償も必要ない。

470 :デフォルトの名無しさん2011/02/19(土) 22:34:27.75

>>468
GITとやらが糞ソフトならLINUXは何ソフト？

471 :デフォルトの名無しさん2011/02/19(土) 22:35:24.29

比較的有用なOS

474 :デフォルトの名無しさん2011/02/20(日) 12:38:06.45

>>471
それじゃWINDOWSは？

472 :デフォルトの名無しさん2011/02/19(土) 23:51:22.82

git grep って
現在いるフォルダとサブフォルダを検索対象にするけど
トップディレクトリ(.gitのあるとこ)以下を検索したいときは
どうすれバインダー
おしえてケロリン

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 するにはどうすればいいんですかね？
そもそも、ブランチ毎にリポジトリサーバ立てるもの？

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 を騙して共用させられればいけるような気もするが…

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で保存しておき、トピックブランチに適用する。

よろしくお願いします｡

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、
それぞれじっくりやってみたらいいと思うよ。

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を元に戻すのが簡単
といったところでしょうか｡

493 :4922011/02/26(土) 15:38:21.40

俺様がよくやる方法みたいな情報も大歓迎です｡

よろしくお願いします｡

497 :デフォルトの名無しさん2011/02/26(土) 23:35:24.82

>496
レスありがとうございます！

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

merge、rebase、stashそれぞれ使いどころがあるってことですね。
φ(..)メモメモ

498 :デフォルトの名無しさん2011/02/27(日) 01:49:19.63

>492
2以外はだいたい一緒
stashは使いどころをまだよく理解していないもんで

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したのかな？

514 :5012011/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/*

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はそれを同じファイルとして扱うから先に作られたファイルが上書きされるんだ。

506 :デフォルトの名無しさん2011/03/07(月) 10:35:15.55

>>504
俺もそれバグかと思った。checkoutでも怒られることあるよ

522 :5032011/03/13(日) 18:59:49.67

遅くなりましたが>>503です。
皆さんの言う通りファイルシステムの違いによるものでした。
ディスクイメージを作ってそこにcase-sensitiveなファイルシステムを
作ってみたところ、正しくチェックアウトできました。
ありがとうございます。

505 :デフォルトの名無しさん2011/03/07(月) 09:16:41.48

となると、OSX的にはcase sensitiveなディスクイメージを作って、それを
マウントして、その中で作業することになりそうだな。
起動ボリューム自体をcase sensitiveにすると、動かなくなる市販アプリが
あったりするのでお勧めしない。

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はそうだよｗ
シェルスクリプト以外はほぼ全部ハードリンクｗｗｗ

515 :デフォルトの名無しさん2011/03/08(火) 01:24:12.96

OSはwindows7
管理するものはC++のソース、
利用人数は１人、
として使うバージョン管理システムで
Gitはオススメできますか？
もしオススメできないとしたら他にはどのような選択肢がありますか？

520 :デフォルトの名無しさん2011/03/08(火) 03:23:00.66

>>515
日本語のファイル名をつけたいなら、日本語WindowsでGitは化けるらしいよ。
UTF-8に対応したCygwinとかいうのなら、大丈夫らしいけど。

521 :515 2011/03/08(火) 16:56:55.40

みなさんありがとうございます。
とりあえずgitの導入に挑戦してみようかと思います。

523 :デフォルトの名無しさん2011/03/14(月) 21:30:25.68

会社はSubversionなんだけど、
自分だけでもGit使ってみようと思って、
さっきgit clone仕掛けて帰ってきた。
明日出社したら終わってるかな?

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 側にコミットもできるよ。

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

524 :デフォルトの名無しさん2011/03/15(火) 02:03:33.89

別に前revision変換しなくてもよくね？

527 :デフォルトの名無しさん2011/03/15(火) 20:50:02.98

ああごめん。
一部だけ持ってきたって話なのか。無視してくれ。

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

535 :デフォルトの名無しさん2011/03/29(火) 18:19:32.52

え、でもファイルがないとコミットできないんですよ(´･ω･`)
リポジトリを作ってすぐにブランチを切りたかったら空のファイルをコミットして、ブランチ切るのが作法なんでしょうか

537 :デフォルトの名無しさん2011/03/29(火) 18:26:23.54

>>535
ブランチの名前は後から自由に変えられる

539 :デフォルトの名無しさん2011/03/30(水) 04:22:50.15

>>535
Gitでは　ブランチ＝コミットに対する別名　なので、
ブランチを"切る" というような動詞から連想するようなことは起こっていない。

どうしてもやりたいなら、こうかな
git init
git symbolic-ref HEAD refs/heads/dev-branch

542 :デフォルトの名無しさん2011/04/01(金) 16:38:06.84

>>536
そうですね空のままは変ですね

>>537-539
あーなるほど
ブランチやタグはコミットに名前をつけているんだということをわかったつもりだったのに理解していませんでした
コミットした後からでこちらの想定の使い方的に問題ないようでした
ありがとうございました

536 :デフォルトの名無しさん2011/03/29(火) 18:23:52.79

つまり、空のディレクトリで git init しましたってことなん？
そして、空のまま git checkout しようとしたってことなん？

頭が空の人間なん？

540 :デフォルトの名無しさん2011/04/01(金) 01:09:49.43

特定のファイルの追加や削除の追跡をしたいのですがよい方法はないですか？
知りたいのはどのリビジョンで追加や削除したのかという情報です
git blame でファイルを指定したらバイナリファイルのせいか画面がぐちゃぐちゃになってひどいことになりました
git blameはソースの変更を追いかけるものだからバイナリはお門違いなのでしょうけど

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"〈文字列〉"

で、〈文字列〉が追加または削除された履歴を確認できる

547 :デフォルトの名無しさん2011/04/08(金) 22:39:43.00

>>545
うわこれめっちゃ便利だ！！！
ありがとう！！！

546 :デフォルトの名無しさん2011/04/08(金) 06:01:22.89

そんな方法があるんですね！
ちょっと調べてみます。ありがとうございました。

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

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

もっと普通はこういうふうにやる、
というのがあれば、教えていただけませんか？

553 :デフォルトの名無しさん2011/04/13(水) 19:41:20.13

>>551
hookかな
なんにしてもコンフリクトする可能性は考えないといけないが

554 :デフォルトの名無しさん2011/04/14(木) 20:31:46.66

>>551です。
ありがとうございました。
たぶん私がまずやるべきはrebaseですね。
それをhookで自動化できるかも...
という感じでしょうか。
ちょっと調べてみます。

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

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`にするのは意味不明。
さらにそれを意味のあるコマンドみたいにして命名するのも意味不明。
単になう言いたいだけちゃうん？

606 :デフォルトの名無しさん2011/04/20(水) 23:43:31.99

>>561
このwipってどういう意味なんだ
ぐぐったら一時的な(gitで言えばstash的な)作業やブランチ、コミットに使われているみたいだけど
ジャーゴン？

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ってブラックリストのことか。普通にボーイズラブかと思ったよ。

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 は変な動作だし

574 :デフォルトの名無しさん2011/04/19(火) 09:34:12.47

GNU EmacsはBazaarで開発されています。
Bazaarに切り替えて下さい。

576 :デフォルトの名無しさん2011/04/19(火) 23:39:07.16

>>574
とは言えemacs向けのbzrに特化したelが有る訳でも無し。

575 :デフォルトの名無しさん2011/04/19(火) 09:57:31.71

Mercurial チートシート http://troter.jp/mercurial-cheatsheet/#sec-1
＞1 はじめに
＞mercurialのチートシートがgithubに上がっていることに疑問を覚えないこと。

577 :デフォルトの名無しさん2011/04/20(水) 14:01:19.09

GitHubで、いくつかプルリクエストしてメインに受け入れられました

…で、自分の公開エリアに残ったブランチどうしましょう
消しちゃっていい？
っていうかプルリクエストの数だけ加速度的に公開済みブランチが増えていく気がするんですが
皆さんどうやって管理してるもんなんでしょうか

582 :デフォルトの名無しさん2011/04/20(水) 15:09:30.06

>>577
orgissue12みたいなブランチ切ってpull requestするようにすれば後から見てもわかりやすい。
上流にマージされたなら消しても問題ないし残してても問題ないし好きにすればいいと思う。

578 :デフォルトの名無しさん2011/04/20(水) 14:32:49.63

プルとプッシュがよくわかりません。

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

で、ローカルでコミットしたあと元のリモートリポリトジに更新分を
送りつけるのがプッシュでいいのかな？

581 :デフォルトの名無しさん2011/04/20(水) 15:05:32.27

>>578
カタカナだとわけわかめになる
pull は英単語
push も英単語

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"ってやる

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

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

595 :デフォルトの名無しさん2011/04/20(水) 17:04:02.50

>>592
その用途なら、俺もDropbox進めるわ。
1ファイルのサイズがでかいというなら外付けHDDと差分バックアップソフトかな。

どうしてもこの系統のソフトが使いたいならSubversion（winならTortiseSVN）で良いんじゃね。

594 :デフォルトの名無しさん2011/04/20(水) 16:53:26.13

ならsvnじゃね？
gitというか分散型だとリポジトリも同じ場所にできるから、ディレクトリごとごっそり消してしまったりしたときに弱い。

ただ、バックアップだけなら素直にOSのバックアップツールを使ったほうが小回りが効くような。

596 :デフォルトの名無しさん2011/04/20(水) 17:15:35.78

Dropboxって無料版だと30日で消されるんだって

598 :デフォルトの名無しさん2011/04/20(水) 17:43:11.84

>>596
いや、普通に毎日ログインするだろｗ
てかおれの1年以上ほかしてたけど内容のこってたわ。

599 :デフォルトの名無しさん2011/04/20(水) 18:30:34.11

>>598
古い変更履歴が消えるってことでしょ

610 :デフォルトの名無しさん2011/04/21(木) 01:09:31.21

>>599
有料なら大丈夫

597 :デフォルトの名無しさん2011/04/20(水) 17:28:08.40

話の途中で申し訳ないが質問していいっすか？
Gitで良く使うコマンドって何？

600 :デフォルトの名無しさん2011/04/20(水) 21:58:05.41

>>597
1. git rebase --continue
2. git checkout
3. git rebase (-i)

マジにネタレス。

608 :デフォルトの名無しさん2011/04/20(水) 23:46:00.99

>>600
え？cloneは？

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/
ですよね、ってことではあるけど、そうじゃない場合もありうるので。

611 :6042011/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.* の保守ブランチを作る。

609 :デフォルトの名無しさん2011/04/21(木) 00:12:36.21

cloneはリポジトリ作成時くらいだからよく使うもんでもないだろう

614 :デフォルトの名無しさん2011/04/21(木) 22:19:31.29

>>609
git clone を cvs checkout と同じ用途で使うバカもいるみたいだぞ。
これが一番確実、とか意味不明なこと言って。

621 :デフォルトの名無しさん2011/04/22(金) 13:33:51.09

>>614
答えは？

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 基本のワークフローにするのがベターと思う。

616 :デフォルトの名無しさん2011/04/21(木) 23:06:49.83

>>613
gitはリモートのファイルにオレオレパッチやオレオレ修正あてたまま、
公式のリリースに追従していくとが楽でいいよね
これだけでもsvnから移行したかいがあった
svnでもできるかもしれないし、gitというか分散型の特徴なのかもしれないけれど

617 :デフォルトの名無しさん2011/04/22(金) 08:02:28.33

>>613
>>616
なるなる。ありがとう。

622 :デフォルトの名無しさん2011/04/22(金) 17:58:49.88

>>611
正当というのがどういうのか分からないけど、
ローカルにタグ、リモートにブランチが欲しいなら、
そういう感じで良いんじゃないですかね。

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

>>612
stashを使うというのも手ですね

615 :デフォルトの名無しさん2011/04/21(木) 22:50:36.78

えﾞ、俺バカだ。
じゃあ作業コピー作りたいときはどうするの？明示的にgit remote add & fetch？

618 :デフォルトの名無しさん2011/04/22(金) 09:48:13.13

地震に備えてソースコードをバックアップして置きたいのですが
GITでオンライン上で非公開でソースコードを置ける無料のサイトってありますか？

620 :デフォルトの名無しさん2011/04/22(金) 12:50:36.57

>>618
mercurialに変換してbitbucket

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はどう？

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

638 :デフォルトの名無しさん2011/04/25(月) 03:15:01.66

>>636
Megauploadにプライベートファイル置いた時並にひでぇｗ
↑個人ストレージのつもりで借りたら丸見えだったでござる

694 :デフォルトの名無しさん2011/05/04(水) 13:07:51.10

>>693
つ>>620

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
というようにしてる
微妙に見にくい

637 :デフォルトの名無しさん2011/04/24(日) 23:03:57.67

>>632
test_vol1が無ければ、これはできるでしょ
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 でコミットメッセージを編集しなおしてる。

661 :デフォルトの名無しさん2011/04/30(土) 16:43:17.27

>>633
core.editorに好きなテキストエディタを設定すればよろし
コミットログに使っている文字コードを指定するのを忘れないようにしてね
テキストエディタの代わりにシェルスクリプトやバッチファイル経由で立ち上げてもいい

適当にググッてきた参考サイト
gitで秀丸を使う方法 - hClippr編集室ブログ
http://d.hatena.ne.jp/unsignedint/20090303/1236138302

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上に作れという話

676 :デフォルトの名無しさん2011/05/02(月) 14:26:16.02

>>646
>バージョン情報を保ちたいなら，リポジトリ自体をDropbox上に作れという話
これやってるけど無茶苦茶便利。
自分の開発機だと別のマシンでもチェックアウトする必要ないんだもん。

677 :デフォルトの名無しさん2011/05/02(月) 16:19:31.09

>>676
それって多人数開発でもうまくいくの？
なんだか一人開発が前提のように見えるけど。

679 :デフォルトの名無しさん2011/05/02(月) 17:09:53.63

>>677
もちろんDropboxは一人だけですよ。
何のための分散型バージョン管理なんですかっ

647 :デフォルトの名無しさん2011/04/28(木) 23:31:45.63

ということは常に最新のファイルは消されないってことですね
でも半年後にサービスが終了したら怖いな

648 :デフォルトの名無しさん2011/04/28(木) 23:56:58.01

>>647
一時期、cronで定期的にzipして自分のgmail口座にメールで送るというのを
バックアップとして使ってた。　

650 :デフォルトの名無しさん2011/04/29(金) 09:29:23.51

>>647
そんな心配していたら、何も使えないだろ。
ローカルのHDDが吹っ飛ぶ可能性だってあるんだぜ。

652 :Perl忍者2011/04/29(金) 23:45:00.87

githubとsvnの違いを説明してください
わかりません
イマイチよくわかりません
メリットデメリットなど

653 :デフォルトの名無しさん2011/04/29(金) 23:45:53.95

githubがphpでsvnがperlだ

655 :Perl忍者2011/04/29(金) 23:47:15.60

>>653
まじめにこたえろはげ

654 :Perl忍者2011/04/29(金) 23:46:53.02

svnっていうやつはサーバー立てるんですか？
githubっていうのはWEBから操作できるやつですか？

バージョン管理システムについておしえてください

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/

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のフォルダに保存したいファイルをコピーするのめんどくせえ

667 :デフォルトの名無しさん2011/05/01(日) 17:06:02.81

>>665
ここ行けば、親切丁寧に教えてもらえるよ。
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

675 :デフォルトの名無しさん2011/05/02(月) 10:25:52.47

>>665
Dropboxは場所が固定だが、
SugarSyncみたいな任意のフォルダを同期できるサービスもあるよ。

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 しか持って来れなくて困りました

674 :デフォルトの名無しさん2011/05/02(月) 09:00:43.41

>>671
git branch は引数を2つ取ることができる(普段は1個)
git branch hoge origin/hoge
とするとリモートにあった hoge が監視下に入る
リモートになにがあったかの情報は git clone した時点で既に手元に来てるので
git branch -a でもして表示しれ

一発ではできない気がするので、適宜使うブランチだけ再現

673 :デフォルトの名無しさん2011/05/02(月) 08:34:47.08

書いたあとで思ったが
git branch -r
を実行したことがあるのだろうか?

681 :デフォルトの名無しさん2011/05/02(月) 18:46:56.77

1つのdropboxを多人数で使うのは集中型的手法。
多数のdropboxを多人数で使うのは分散的手法。

682 :デフォルトの名無しさん2011/05/02(月) 20:07:14.88

多数のdropboxを使うと言ったって共有する部分は集中型じゃん。

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日以内にファイルをコミットし続けないといけないのでしょうか？
そのへんはマクロとか使えば何とかなりますが・・・

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には置かないがこれは俺の判断だし

695 :デフォルトの名無しさん2011/05/04(水) 13:23:35.48

>>688
> ここにgitのリポジトリを作ればいいんですか？
まずやってみろよ

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

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

> それと、30日でファイルが消えるってありますが、30日以内にファイルをコミットし続けないといけないのでしょうか？
Dropboxスレで聞けよ

693 :デフォルトの名無しさん2011/05/04(水) 12:57:43.83

だってさ無料で非公開で管理できるサーバが欲しかったんですよ
俺は金がないから自分でどりょくしてここまで来たのですよ

696 :デフォルトの名無しさん2011/05/04(水) 13:34:16.16

やりたいんですけど壊れたら怖いので聞いてみたのですよ
お年玉も使っちゃったし自分でパソコン変えないしまだ小５だから

699 :デフォルトの名無しさん2011/05/04(水) 14:44:44.39

バージョン管理システム動かしたくらいでPCが壊れるわけねーだろ
Gitどうこう以前に頭が弱すぎて話にならん

マイクロソフトワイヤレスブルートラックマウス Arc Touch Mouse RVF-00006
マイクロソフトワイヤレスブルートラックマウス Arc Touch Mouse RVF-00006

コメント一覧 (8)

- 1. web design vancouver
- 2012年02月20日 06:22
- こんにちは、あなたが使用しているブログのプラットフォームを示すいいでしょうか？私はすぐに自分のブログを開始するつもりですが、私はBlogEngine/Wordpress/B2evolutionとDrupalの間で選択を困難な時期を過ごしています。デザインとスタイルは、ほとんどのブログ、異なるようなので私が尋ねる理由は、私はユニークなものを探しています。オフトピックであるために私の謝罪PS私はお願いしました！
- 2. payday loans
- 2012年03月06日 12:27
- 私は仕事であった一方、今日、私のいとこは私のiPadを盗んだ、それは40フィートの降下、ちょうど彼女はYouTubeの感覚があるかを生き残ることができるかどうかを確認するためにテストされています。私のApple iPadが今破壊され、彼女は83景色を眺めることができます。私はこれが完全にオフトピックです知っているが、私は誰かとそれを共有していた！
- 3. payday loans in calgary
- 2012年03月29日 11:36
- 私は、あなたのブログを愛して..とても素敵な色＆テーマ。このウェブサイトを自分で設計したか、またはあなたはあなたのためにそれを行うために誰かを雇うのですか？私は自身のブログを構築するために、uはからこれを持ってどこに知っていただきたいと思い探しているようにplzは戻って答える。ありがとう
- 4. toronto payday loans
- 2012年04月11日 12:24
- おい！あなたはTwitterを使用していますか？私は、それが大丈夫ならばあなたをフォローしたいと思います。私は絶対にあなたのブログを楽しんでいると、新しい更新を楽しみにしています。
- 5. canada cash advances
- 2012年04月13日 11:20
- こんにちは、あなたが使用しているプラットフォームを共有するブログを気にしますか？私はすぐに自分のブログを開始する予定ですが、私はBlogEngine/Wordpress/B2evolutionやDrupalとの間で決定する困難な時期を過ごしています。デザインとスタイルは、ほとんどのブログ、異なるようなので私が尋ねる理由は、私は完全にユニークな何かを探しています。オフトピックであるのPS謝罪が、私はお願いしました！
- 6. dentist los angeles
- 2012年04月14日 04:59
- ヘイ！これは、オフトピックのようなものですが、私は、確立されブログからいくつかの助けが必要です。それはあなた自身のブログを設定するには厳しいでしょうか？私は非常にtechincalませんが、私はかなり速いものを把握することができます。私は自分自身を作成する方法について考えているが、私は開始する場所がわからないんだ。あなたは、任意の点やご提案をお持ちですか？多くの感謝
- 7. payday loans calgary
- 2012年04月25日 11:08
- 今それがBlogEngine今そこに最高のブログのプラットフォームであるように聞こえる。（私が読んだから）、あなたのブログに何を使用していることありますか？
- 8. car title loans california
- 2012年05月08日 14:00
- チェックボックスをオンにし、 "新しいコメントが追加された時を知らせて！ "私はもともとコメントアウトとき、私はクリックして現在のたびは、コメントは、私が同じコメントで4つのメールアドレスを追加取得が追加されます。あなたはそのサービスから私を削除することができますどのような方法はありますか？どうもありがとう！