Git 3

1 ：デフォルトの名無しさん：2011/07/12(火) 01:53:58.45

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/

◆前スレ
Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/

◆関連サイト
Pro Git - Table of Contents
http://progit.org/book/ja/
Git入門
http://www8.atwiki.jp/git_jp/

2 ：デフォルトの名無しさん：2011/07/12(火) 01:54:43.65

◆過去スレ
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/

◆関連スレ
バージョン管理システムについて語るスレ8 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1295493964/

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 r13 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1286654542/
【分散型バージョン管理】 Mercurial 【hg】 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

3 ：デフォルトの名無しさん：2011/07/12(火) 01:55:12.45

◆関連書籍
入門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 ：デフォルトの名無しさん：2011/07/12(火) 17:29:28.17

１おつ

5 ：デフォルトの名無しさん：2011/07/12(火) 18:34:06.53

まんこまんこです。夏中には何かパッチ送ってみます。

6 ：デフォルトの名無しさん：2011/07/13(水) 07:30:17.19

リモート系のコマンドとブランチとheadとかがよくわかんない

7 ：デフォルトの名無しさん：2011/07/13(水) 12:12:01.18

みなさん CHANGELOG どうやって書いてますか
書かないわけにもいかないし…

8 ：デフォルトの名無しさん：2011/07/13(水) 12:20:50.21

ChangeLog は書式がいろいろあるからなあ

ぶっちゃけ気に入ったのをどっかから持ってきてバージョンごとにコピペして手作業で追記して使うというのがメジャーかと思う
git log --pretty=%s とかで git のログはまとまるので、適当にコピペして貼ったり切ったり

9 ：デフォルトの名無しさん：2011/07/13(水) 12:26:43.09

Git流の開発スタイルだと ChangeLog なんて綴ってられんよな?

10 ：デフォルトの名無しさん：2011/07/13(水) 12:28:07.75

連投スマンが、 ChangeLog(.txt) のコンフリクトを解消するのって本質的な作業じゃないよな。

11 ：デフォルトの名無しさん：2011/07/13(水) 13:16:39.40

>>9
コミットログとチェンジログは役割が違う
チェンジログはまとめ広報に近い
「今回のバージョンの変更点はgitのコミットログ見てくださいね^^v」というのは現状極めて不親切だ

…いや、まあ、不親切でもいいんだけど、不親切だという謗りは免れないだろう
コミットごとにコミットについての追加変更著者情報が書かれているのがコミットログで、
バージョンパッケージングごとにバージョン間の動作の変更点と注意が書かれているのがチェンジログだと思う

実際にいつ誰がツリーにコミットしてソース上の変更行がどこかなんてのはチェンジログには不要というか余分

12 ：デフォルトの名無しさん：2011/07/13(水) 13:29:02.57

redmineのチケットと連動させれば？

13 ：デフォルトの名無しさん：2011/07/13(水) 14:26:15.90

>>11
思うのは勝手だが一般的な流儀とはかけ離れてるなｗ

14 ：デフォルトの名無しさん：2011/07/13(水) 14:37:52.70

このへん、普段どんなプロジェクト追っ掛けてるかによってもけっこう違う気はする
ブランチと pull リクエストの散発的な日付のマージが連打してる git のコミットログから
前バージョンとの変更点を見つけるのは、ものによってはかなりめどい
ソース上どんな変更があったのかは自明だが、それが意味するのはナンデスカみたいな

15 ：デフォルトの名無しさん：2011/07/13(水) 14:46:55.71

>>11
> バージョンパッケージングごとにバージョン間の動作の変更点と注意が書かれているのがチェンジログだと思う
オレはそれはリリースノートだと思うなぁ

16 ：デフォルトの名無しさん：2011/07/13(水) 14:50:31.40

なんというか、「ここで変数 i に10を代入」的な1行コミットログを書く人がいると、なんかとてもめんどくさくなる感じ
ひとつひとつのコミットがきちんと有機的に構成されて説明が充分であれば、コミットログだけでなんとかなるんじゃないかと

でも普通はそんなコミットなんてしないよね
めんどくさいし、整合性も取りづらいというかむしろ全く取れない
「update README」ではなく、README に何を書いたかきちんとコミットログに書いてる？
「merge branch xxxx」ではなく、そのブランチのマージによってソフトウェアに何が起こるかきちんと説明書いてる？

17 ：デフォルトの名無しさん：2011/07/13(水) 23:06:56.91

ひと山いくらで動いてる人ですら、書いているというのに…

18 ：デフォルトの名無しさん：2011/07/14(木) 06:32:00.47

あんま書いてない例のほうが多い気がす
せめて何がどう直ったのかくらいは書いて欲しい

19 ：デフォルトの名無しさん：2011/07/14(木) 12:09:00.50

GNU だと ChangeLog は開発者用で commit log message そのもの、
利用者向けには NEWS を用意することになってるね。
git だと GNU的な ChangeLog はいらんような気がする

20 ：デフォルトの名無しさん：2011/07/18(月) 23:42:24.33

883 デフォルトの名無しさん [sage] 2011/07/18(月) 21:51:31.64 ID: Be:
gitって、mq相当のことはひたすらローカルリポジトリ内でcommitを整形していく感じなんだな。
ローカルとは言えcommitしたのをいじくり回すってのは結構違和感がある。

ってなことをgitのスレに書くといろいろありそうなのでここに書く。

21 ：デフォルトの名無しさん：2011/07/18(月) 23:44:02.94

884 デフォルトの名無しさん [sage] 2011/07/18(月) 23:22:29.36 ID: Be:
同種ツールの一長一短、ポリシーの違いだからなぁ
使ったことないけどbazaarも同じようなことしようとするとmercurialとまったく同じにはならんのだろう

22 ：デフォルトの名無しさん：2011/07/19(火) 00:02:58.01

>>5
言っとくけど git.vger の Signed-off-by は実名限定だからな。
そのふざけたハンドルを2chで名乗ってるのが誰なのかバレるぜ。

23 ：デフォルトの名無しさん：2011/07/19(火) 02:05:05.44

よく知らないけど mq ってパッチ管理のはずだから
同じことをしたいのなら StGIT とか Guilt になるんじゃないかな
オレの感覚だと git でできるコミット整理ができないから
パッチ管理の mq でお茶を濁している感じ
何か意図するところがあってそういう設計にしているってことなのかもしれないけど

24 ：デフォルトの名無しさん：2011/07/19(火) 10:05:55.10

Advanced uses of Mercurial Queues
http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch13.html

25 ：デフォルトの名無しさん：2011/07/19(火) 12:12:20.37

>>22
2chで実名でカキコするワケねーだろ。
Junioに向かってまんこまんこを名乗るワケねーだろ。

26 ：デフォルトの名無しさん：2011/07/19(火) 12:23:38.38

1まんこタグに関する修正のコミットを実名つきでしたら、
このスレに1まんこ1まんこと書き込んでた人と紐づけされるという話だろう

…まあ、1まんこはただの1まんこで別に他の意味もないし、
1まんこという表現を使う人は（2chみたいなところでは）珍しくもないが

27 ：デフォルトの名無しさん：2011/07/19(火) 12:53:52.72

ちなみに10まんこタグ(ML上では 10k of refs)は遠い将来の課題にして、
さしあたってはスマートタグみたいなものを実現してみようと思う。
git-svn/.rev_map とか notes の情報を lightweight tag と同等に扱えるようにする感じ。

Git はともかく他のオプソも本業ではないので、進捗を急かさないでね。
まんこまんこ

ところで git-notes って活用されてる?

28 ：デフォルトの名無しさん：2011/07/19(火) 13:06:29.73

素で位取り間違えたが10kじゃなく100k

29 ：デフォルトの名無しさん：2011/07/19(火) 14:32:56.99

日本名でパッチ投げるのはそう居ないし、内容見たらバレバレだろｗ
職場でまんこさん呼ばわりされる日も近いｗ

30 ：デフォルトの名無しさん：2011/07/19(火) 19:52:38.13

質問させてください。
windows7 32bitにturtoisGitをインストールしたあと
右クリックのgit cloneを押すと
git have not installed が出てしまいます。
これはどのようにすれば解決するか教えてください。

31 ：デフォルトの名無しさん：2011/07/19(火) 20:06:09.09

msysgitなどをｲﾝｽ子しろとリリースノートに書いてなかった？
まんこまんこ

32 ：デフォルトの名無しさん：2011/07/19(火) 20:07:36.09

さらしあげ

33 ：デフォルトの名無しさん：2011/07/19(火) 20:16:46.76

Git-1.7.6-preview20110708.exe
は入っているのですが、git have not installedが出ます。
エラーの原因がわかりません。アドバイスをお願いいたします。

34 ：デフォルトの名無しさん：2011/07/19(火) 20:28:31.77

git.exe のpathを設定する場所が Settings... にない?
まんこまんこ自らあげ

35 ：デフォルトの名無しさん：2011/07/19(火) 21:07:29.34

ありがとうございます！
夕方から迷っていましたがやっと使えるようになりました！
まんこ紳士さん本当にありがとうございます！

36 ：デフォルトの名無しさん：2011/07/19(火) 21:38:43.29

まだ若いんだから中年のおっさんみたいなマネはやめろよ

37 ：デフォルトの名無しさん：2011/07/19(火) 23:05:37.81

まんこはホントに大好きだが君たちGitについて語ってくれ
Gitそのものをほげるのはもあべたー

38 ：デフォルトの名無しさん：2011/07/20(水) 00:00:21.28

俺だってまんこ大好きだしここはGitスレなんだからもちろん
Gitについて語りたいけど、無駄にまんこ連呼する奴と絡もうとは
思わないな。そういうヤツの相場はまあたいていアレだよ。。。

39 ：デフォルトの名無しさん：2011/07/25(月) 20:45:28.08

Macな知り合いにTower勧めようとしたんだけど、これって有償なのか。
もしかしてAll in Oneなパッケージなわけじゃなくて、ただのフロントエンド？

40 ：デフォルトの名無しさん：2011/07/25(月) 20:52:22.91

自分が使ってもないものを他人に勧めるのか・・・？

41 ：デフォルトの名無しさん：2011/07/25(月) 21:42:24.81

いや、自分WINなんですけど、Macだと簡単に操作できるアプリあったよな…
という記憶から引っ張り出してきまして。

42 ：デフォルトの名無しさん：2011/07/25(月) 21:56:25.64

>自分が使ってもないものを他人に勧めるのか・・・？
まんこのこと?

43 ：デフォルトの名無しさん：2011/07/25(月) 22:21:54.10

管卵

44 ：デフォルトの名無しさん：2011/07/26(火) 00:13:55.69

まんこを使わない奴らによってちんぽスレになりそうな悪寒

45 ：ななし。：2011/07/27(水) 15:49:03.17

カ　オ　ス　ラ　ウ　ン　ジ　ゆ　る　せ　な　ぁ　い　ー

46 ：デフォルトの名無しさん：2011/07/28(木) 23:08:55.69

git svnで作ったリポジトリから簡単にsubversion向けのパッチを作れないですかね
exportしたzipファイルをsvnの作業コピーに上書きするのは面倒です

47 ：デフォルトの名無しさん：2011/07/28(木) 23:26:22.56

俺が参加してるsvnプロジェクトだと git diff のパッチ
それどころか git-format-patch ですら歓迎してくれるぞ。
(patch -p1 -N で食えることを皆知ってるからね)

つか SVN 専だったとしても patch -p0 じゃないの?

48 ：デフォルトの名無しさん：2011/07/29(金) 00:08:51.36

git で cvs udpate -D 2011-03-11 みたいなことをするには
どのようにすればよいですか？

49 ：デフォルトの名無しさん：2011/07/29(金) 01:55:26.69

svnコマンドもだいぶ忘れまくってるけど、cvsはもう完全に無理だな
何にも思い出せない

50 ：デフォルトの名無しさん：2011/07/29(金) 17:24:10.89

SVN向けのパッチ、なんてあるんだっけ？専用のフォーマット？

51 ：46：2011/07/29(金) 20:04:29.30

git diffで作ったパッチだとTortoiseMergeで開けないみたいなので
この２つを試しましたが、構文エラーが出て全く動きません！

http://mojodna.net/2009/02/24/my-work-git-workflow.html
http://abombss.com/blog/2007/12/10/creating-patches-for-subversion-from-git/

52 ：46：2011/07/29(金) 20:07:52.82

エラーメッセージはこんな漢字でした

http://mojodna.net/2009/02/24/my-work-git-workflow.html

\git-svn-diff\git-svn-diff.sh: line 14: conditional b
inary operator expected
\git-svn-diff\git-svn-diff.sh: line 14: syntax error
near `=~'
t\git-svn-diff\git-svn-diff.sh: line 14: `if [[ "$TRAC
KING_BRANCH" =~ URL.* ]]'

http://abombss.com/blog/2007/12/10/creating-patches-for-subversion-from-git/

Traceback (most recent call last):
File "\git-svn-utils/git-svn-diff", line 24, in <mo
dule>
svn_rev = get_output(['git-svn', 'find-rev', treeish]).read().strip()
File "\git-svn-utils/git-svn-diff", line 6, in get_
output
p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
File "c:\Python27\lib\subprocess.py", line 672, in __init__
errread, errwrite)
File "c:\Python27\lib\subprocess.py", line 882, in _execute_child
startupinfo)
WindowsError: [Error 2] 指定されたファイルが見つかりません。

53 ：デフォルトの名無しさん：2011/07/30(土) 15:38:41.67

Git GUIでファイルを右クリック→git historyで当該ファイルのみに絞った変更履歴が出せて便利なのですが、
これに相当する操作をコマンドラインのみで行えないでしょうか？

54 ：デフォルトの名無しさん：2011/07/30(土) 16:28:39.58

ブランチにコメントを付けるような機能ってないでしょうか？
ブランチ名だけだと何のためのブランチか忘れてしまうことがあって…

55 ：忍法帖【Lv=30,xxxPT】：2011/07/31(日) 00:04:08.01

なんで、そんなに大量にブランチ作っているわけ？

作業したらマージしないの？

個人でのブランチは、plainテキストか、wikiで管理してればいいと
思うけど。担当者名/hogehoge-feature とか fuga-fixとか他人から
見えるのは、変数名同様にちゃんと考えているのだろうか。

56 ：デフォルトの名無しさん：2011/07/31(日) 00:21:14.30

>>53
gitgui使わないから分かんないんだけど、普通に git log パスじゃダメなん？

57 ：デフォルトの名無しさん：2011/07/31(日) 07:04:46.54

>>55
git merge --no-ff とやって、担当者名/hogehoge-feature がログに残ることを義務付けている宗派がある

58 ：53：2011/07/31(日) 11:51:18.53

>>56
>>>53
>gitgui使わないから分かんないんだけど、普通に git log パスじゃダメなん？

変更履歴という書き方がわかりずらかったですね、すいません
当該ファイルのみのコミットログも見れるに越したことはないのですが、
一番見たいのは当該ファイルのみのリビジョン間のdiffなんです

59 ：デフォルトの名無しさん：2011/07/31(日) 13:22:00.86

60 ：デフォルトの名無しさん：2011/07/31(日) 16:43:03.52

>>58
git diff --help

61 ：デフォルトの名無しさん：2011/07/31(日) 17:16:37.48

>>58
git log -p パス

62 ：デフォルトの名無しさん：2011/07/31(日) 20:22:40.60

>>55
趣味で組んでるものなので、wiki使うほど大げさではないし、
下手すりゃ数か月後に続きを、みたいなことがあるので
ブランチ名見返してもよく思い出せないことが…

63 ：デフォルトの名無しさん：2011/07/31(日) 20:32:20.29

ブランチ名でログを表示させればいいんじゃないのかな？
そのブランチでやってる作業についてのログを読めば、
なんのブランチか思い出すんでは。

64 ：デフォルトの名無しさん：2011/08/01(月) 12:35:17.57

コミットログをちゃんと書いてれば
ブランチのコメントとか言い出さないと思うんだが。。。

65 ：デフォルトの名無しさん：2011/08/01(月) 17:56:12.27

素直にSourceForge使うことにしました…

66 ：デフォルトの名無しさん：2011/08/09(火) 18:52:10.49

SVNからGitへのリポジトリ移行を考えています。

git-svn clone でSVNのリポジトリをとってくると、SVN上のbranch/tagに代わる
git上のbranchが大量にできるのですが、
このbranchを全てpushする方法というのはあるのでしょうか？

67 ：デフォルトの名無しさん：2011/08/09(火) 19:26:28.91

ある

68 ：デフォルトの名無しさん：2011/08/09(火) 20:04:45.37

>>67
どうすれば良いのでしょう？

69 ：デフォルトの名無しさん：2011/08/09(火) 21:09:50.91

http://stackoverflow.com/questions/1914579/set-up-git-to-pull-and-push-all-branches
ですかね？でもリモートブランチを直接pushとかできるんでしょうか…？

70 ：デフォルトの名無しさん：2011/08/10(水) 11:31:39.72

githubで変換できますね。
http://help.github.com/import-from-subversion/
今回はこれで十分かも…

71 ：デフォルトの名無しさん：2011/08/10(水) 11:39:19.83

>>70
試してみたらgit svn cloneしてるだけでした…git2svnの説明と共にあったのでてっきりbrach/tagも同期してくれるものかと。

72 ：デフォルトの名無しさん：2011/08/13(土) 17:46:10.88

使い始め初心者です。
git add .とgit commitって、どっちも現在の状態を記録する的なイメージで、漠然としか理解していないのですが、
最終的にはcommitしないとgitとしてはセーブされないのですよね？
これらのコマンドが何をやってるのかをわかりやすく教えていただけないでしょうか？

73 ：デフォルトの名無しさん：2011/08/13(土) 17:58:06.14

add は新しいファイルをgitに登録する
commit は変更を記録する

74 ：デフォルトの名無しさん：2011/08/13(土) 18:01:00.91

stageでググるとaddが何してるかわかるかな

75 ：デフォルトの名無しさん：2011/08/13(土) 21:14:56.89

add .を連発するのは非推奨なのですね。

76 ：デフォルトの名無しさん：2011/08/13(土) 21:28:55.22

1ファイルであってもadd -pで変更箇所ごとにログを付けてはコミット。

77 ：デフォルトの名無しさん：2011/08/14(日) 00:52:54.20

HEADに^をつけると1つ前のバージョン、HEAD^^は二つ前のバージョンって理解でよろしいでしょうか。

78 ：デフォルトの名無しさん：2011/08/14(日) 03:06:16.02

>>77
HEAD^は1つめの親
HEAD^^は1つめの親の1つめの親

マージコミットの場合は複数の親があるので、2つめの親を指定するには
HEAD^2のようにする。

79 ：デフォルトの名無しさん：2011/08/14(日) 04:05:38.81

親ってのが何を指すのかが分からないのですが、
1つ前の親というのは、HEADの一つ前のコミットを指すのですか？
それとも、分かれたブランチの元にあるコミットを指すのですか。

80 ：デフォルトの名無しさん：2011/08/14(日) 05:23:04.50

GitHubに登録したのはいいけれど、インターフェイスが英語だ。
日本語表記にできるみたいなのでしたいのだがどうすればいいですか？

81 ：デフォルトの名無しさん：2011/08/14(日) 06:02:40.76

>>72
git commitといっても今の変更内容を全ていっぺんにコミットしたくない場合もある。
ある目的をもってコード書いてるときに別のちょっとしたバグを見つけて直してしまったり。
あとから問題が発生してこのコミットをとりやめなきゃならなくなったときに後者のバグも生き返ってしまう。
そんなときのために、まずgit addでコミット予定の変更を選択して個別にコミットするよう2段階の構成になってる。
詳しくはステージングでググれ。
良いコミットを。

82 ：デフォルトの名無しさん：2011/08/14(日) 06:05:18.89

>>79
git log --all --graph
して見えるグラフのコミットとコミットの間の線が親子関係。

83 ：デフォルトの名無しさん：2011/08/14(日) 07:56:56.50

>>80
日本語UIはこないだ廃止になった。超がんがれ。

84 ：デフォルトの名無しさん：2011/08/14(日) 14:11:25.61

>>79
とりあえず>>1のProGitとGit入門読んだらどうか。

>>83
あれなんで廃止になったんだろうね。
最近はGit本家もその辺前向きに進んでるのに。

85 ：デフォルトの名無しさん：2011/08/15(月) 01:24:22.39

>>82
1つめの親、2つめの親、というのはどうやって決まるんでしょうか

86 ：デフォルトの名無しさん：2011/08/15(月) 22:55:29.20

いつの間にかTortoiseGitの1.7.2.0が出てた
試してみよう

87 ：デフォルトの名無しさん：2011/08/16(火) 17:04:21.83

git reset --hard HEAD^すると、
More?
More?
fatal: ambiguous argument 'HEAD
': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
となるエラーは何が悪いのでしょうか？

88 ：デフォルトの名無しさん：2011/08/16(火) 17:15:23.42

あと、Win版のPortableGit-1.7.6-preview20110709は、git-bashを起動しても、
bash:tset:command not found
と出て動作が止まってしまうんだが、これって俺だけですか？

89 ：デフォルトの名無しさん：2011/08/16(火) 19:32:18.39

夏の勘違いの悪寒

90 ：デフォルトの名無しさん：2011/08/16(火) 20:06:56.84

HEAD^ の ^ がシェルで何かに解釈されてるんじゃないの?
やるなら git reset --hard 'HEAD^' とか。
> 88
古い UNIX マシンからそのままコピーしてきた .bashrc あたりが残ってるとか。
.bashrc あたりで test と tset を間違えてるとか。

91 ：デフォルトの名無しさん：2011/08/16(火) 20:18:03.34

>>87
^で複数行入力はcmd.exeの仕様。
""で囲めば行けるはず。

92 ：デフォルトの名無しさん：2011/08/16(火) 20:48:16.24

>>90本当だ。.bashrc消したらいけました。
>>90 >>91
確かにコマンドプロンプトが解釈してました。
コマンドプロンプトはシングルクォートも通らなかったりして、使うのが鬱陶しいですね。

93 ：デフォルトの名無しさん：2011/08/16(火) 21:07:37.52

Win版のgit-bashで起動時のカレントディレクトリを変更するには、どこをどういじればいいでしょうか？

94 ：デフォルトの名無しさん：2011/08/17(水) 02:11:10.03

付属のGit Bash.vbsをいじって初期cdを変更しておきたいのですが。

95 ：デフォルトの名無しさん：2011/08/20(土) 10:41:56.52

gitをwebdavでってことで、bareを設置してなんとか使えてはいます。
pushできるユーザーにはwebdavへの権限を与えるわけですが、
これって、pushできるユーザーはwebdavに直接アクセスし、
bareのファイルを生で触ってリポジトリの破壊等ができてしまうようです。
ちょっとまずくないですか？

コミッターなんだから破壊権限までありますよ。
気をつけてつかいましょう、っていう思想なのでしょうか……。

96 ：デフォルトの名無しさん：2011/08/20(土) 11:01:30.51

ユーザは全員、リポジトリ全体のコピーを丸ごと clone して持ってるのだから、
破壊されても誰かのリポジトリからコピーし戻せばいいだけじゃね

97 ：95：2011/08/20(土) 13:06:07.35

>>96
davでの公開って、共有スペースにbareを置いてるだけなので
あまり期待できないっぽいですね。
pushを途中で切断したり、耐久テストしてたらやっぱり壊れました。

他にはdavのPUTできる場所を限定して、DELETEを禁止とかで
なんとか運用できないものかと考えてます。

98 ：デフォルトの名無しさん：2011/08/20(土) 13:32:54.37

Gitの仕組み上、pushを途中で切断して壊れるってのは無いと思うけどなー

99 ：95：2011/08/20(土) 16:15:35.83

>>98
davがLOCKしたままになってたようです。
timeoutを設定しました。

100 ：デフォルトの名無しさん：2011/08/25(木) 12:50:21.30

次期OSS標準はそろそろ決まって欲しい
今の勢力って git>hg>bzr なかんじ？

101 ：デフォルトの名無しさん：2011/08/25(木) 15:07:22.35

GoogleCodeがGit受け入れて、ほぼ趨勢は決したんじゃないかな

102 ：デフォルトの名無しさん：2011/08/26(金) 11:02:29.54

復活？

103 ：デフォルトの名無しさん：2011/08/26(金) 11:36:44.71

test

104 ：デフォルトの名無しさん：2011/08/27(土) 03:10:23.55

gitのややこしいコマンド体系、というか破綻してるコマンド体系を
なんとかしようという動きはないのかな。

105 ：デフォルトの名無しさん：2011/08/27(土) 11:04:02.99

慣れると気にならないからなぁ

106 ：デフォルトの名無しさん：2011/08/27(土) 15:08:42.70

慣れると、つーか、開発のスタイルをgitに合わせないといけなくて、
そのスタイルでやるとすんなり来る感じ。
gitのモデルとする開発スタイルは従来のバージョン管理システムとはわりと違う感じ。

107 ：デフォルトの名無しさん：2011/08/27(土) 16:56:18.65

そういう問題じゃなくてだなぁ、他の分散管理に比べてもコマンド体系がおかしいんだよ
信者もいるし、gitの気持ち悪さは暗黙の了解だけとも

108 ：デフォルトの名無しさん：2011/08/27(土) 17:12:14.06

>>104
EasyGit
http://people.gnome.org/~newren/eg/

109 ：デフォルトの名無しさん：2011/08/27(土) 17:53:18.24

TortoiseGit

110 ：デフォルトの名無しさん：2011/08/27(土) 19:23:41.66

>>107
詳しく

111 ：忍法帖【Lv=6,xxxP】：2011/08/27(土) 20:16:34.12

質問です
ファイアウォールのためネットワーク越しにgit cloneできない環境で
これと同等のことをしたいのですが、
.gitディレクトリ以下を丸ごと相手に渡せば大丈夫ですか？
また、この方法でまずい点はありませんか？

112 ：デフォルトの名無しさん：2011/08/27(土) 20:32:36.72

>>111
それで全データ渡せるけど、無駄なモノもけっこう含まれちゃうかも。
渡す前にgit gcしとけば多少は無駄が省けると思う。

113 ：111：2011/08/27(土) 20:48:04.37

>>112 分かりました
ありがとうございます

114 ：デフォルトの名無しさん：2011/08/27(土) 21:48:14.57

Gitのコマンド面倒くさ
GUI使えないのかな

115 ：デフォルトの名無しさん：2011/08/27(土) 21:49:54.27

TortoiseGit

116 ：デフォルトの名無しさん：2011/08/27(土) 22:17:31.40

>>107
多いのは信者じゃなくてアンチだろｗ
コマンドの数が多いとか難癖つけてさ。
おおかたウインドウズ大好きでC++信者なんだろうが、
頑張ってDISってる姿は滑稽だよ。

117 ：デフォルトの名無しさん：2011/08/27(土) 22:34:58.85

まさに信者だな

118 ：デフォルトの名無しさん：2011/08/27(土) 23:49:04.17

>>111
そういう時はgit bundle使うんじゃなかったっけ

119 ：デフォルトの名無しさん：2011/08/28(日) 01:01:55.19

preview20110708ベースのUTF-8ファイル名対応版 Gitで
日本語ファイルやディレクトリのaddやcommitはできるんだが、
日本語ディレクトリを含むパスでのinitができないのは俺だけ？

120 ：デフォルトの名無しさん：2011/08/28(日) 04:18:53.32

AAA 中のファイル：
　　　　*aaa.c　　　　*bbb.c　　　　ccc.c　　　　*Makefile　　　　a.out
（*は、commitされてるファイルだとして）

git clone AAA BBB で複製した場合
BBB 中のファイル：
　　　　*aaa.c　　　　*bbb.c　　　　*Makefile

cp AAA BBB -r で複製した場合
BBB 中のファイル
　　　　*aaa.c　　　　*bbb.c　　　　ccc.c　　　　*Makefile　　　　a.out

cp だと、コミット忘れしてる ccc.c も渡せて便利ｗ a.outのようなゴミも渡すけど。

121 ：111：2011/08/28(日) 08:40:26.10

>>118 man読みました
まさにこれがやりたかったんです
ありがとうございます

122 ：デフォルトの名無しさん：2011/08/28(日) 09:05:35.14

>>119の書き込み見てUTF-8対応版の最新版が来てたのを知った
㌧

123 ：デフォルトの名無しさん：2011/08/29(月) 22:43:10.78

>>120
いやコミットし忘れてるんならまずコミットしろよｗ

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

gitの管理を完全にやめるとき、あるいはリセットするとき、
.gitディレクトリを削除すればそれで完全にリセットできますか？

125 ：デフォルトの名無しさん：2011/09/01(木) 01:23:39.58

>>124
管理をやめるなら.gitを消せばいい。
リセットというのがどういう動作を指すのかわからんのだが、
仮にバージョン管理を始める前の状態に戻すという意味なら、
.gitを消すだけでは元に戻せない。

126 ：デフォルトの名無しさん：2011/09/01(木) 01:40:26.81

ありがとうございます。管理をやめるだけで、別にファイルは現状のままでいいので、
それで解決します。

127 ：デフォルトの名無しさん：2011/09/01(木) 12:01:29.02

error: SSL certificate problem, verify that the CA cert is OK. Details:!!!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing ＜URL＞

fatal: HTTP request failed
exit 128 "＜URL＞"
と出て、cloneできないんですけど、どうすればいいでしょうか？

128 ：デフォルトの名無しさん：2011/09/01(木) 15:19:15.22

>>127
cloneしなければいいよ

129 ：デフォルトの名無しさん：2011/09/01(木) 15:42:23.64

エスパーすると、githubにhttpsでアクセスしてる？

130 ：デフォルトの名無しさん：2011/09/01(木) 16:04:39.87

>>129
あ。してます。もしかしてGit Read-Onlyで出てくるアドレスの方を入力するべきなのか。

131 ：デフォルトの名無しさん：2011/09/02(金) 07:17:15.65

エスパーどころかエラー内容全部書いてるだろｗｗ
証明書が確認できないんだとさ、
取得できないならURLと権限を確認しろ
不一致か期限切れなら-fしてみろ
ついでに後者なら鯖管に報告しろ

132 ：デフォルトの名無しさん：2011/09/02(金) 07:19:30.44

エスパーしたのはgithubの部分か、
すまん早とちりだ

133 ：デフォルトの名無しさん：2011/09/02(金) 18:01:55.65

>>127
http://d.hatena.ne.jp/tmatsuu/20110614/1308010044

134 ：デフォルトの名無しさん：2011/09/02(金) 18:35:14.59

>>133
おおこれは。ありがたいです。

135 ：デフォルトの名無しさん：2011/09/04(日) 14:46:51.52

git apply が当たらない
パッチ読んでもファイル読んでも絶対に適用できる自信がある小さなコミット由来なんだが、でも git apply -v でエラーが出る

…まあ、どうせどっかで間違えてるんだろうけど、ぜんぜん見えねえ
昼寝でもするか…

136 ：デフォルトの名無しさん：2011/09/06(火) 16:50:50.98

"main"と"test"というブランチがあるとして、
testで作業しててcommitやmergeしたら、じつはmainにいたので(略
みたいな事態を避けるために、
特定のブランチに対しては、特に明示しない限りcommitなどをさせない、
ようするに特定のブランチを保護しとくみたいな方法ってありますか？
まだgit自体使い始めでよくわかってないので、ヘンなこと書いてるかもしれませんが...

137 ：デフォルトの名無しさん：2011/09/06(火) 19:32:55.55

コミットをよそに晒してない限り reset も rebase もし放題だ。精一杯失敗しまくれ。

Gitではコミットはなかなか消えん。しばらくは git reflog がトモダチだな。

138 ：136：2011/09/06(火) 20:37:50.52

>>137
reflog でググりました
安心して失敗しまくることにします

139 ：デフォルトの名無しさん：2011/09/06(火) 21:07:40.73

俺はgit-completionでPS1書き換えてブランチ名出すようにしてるな。

140 ：デフォルトの名無しさん：2011/09/06(火) 22:08:09.03

pre-commitフックで拒否するとか。自分はマスターブランチへのコミットは全部弾いてる。

141 ：デフォルトの名無しさん：2011/09/08(木) 16:48:59.16

GitHubからのNotificationsが、メールアドレスにも転送されてくるのですが、これを停止する方法はありませんか？

142 ：デフォルトの名無しさん：2011/09/08(木) 17:24:43.02

あります。

143 ：デフォルトの名無しさん：2011/09/08(木) 19:10:09.91

教えていただきたいのですが。

144 ：デフォルトの名無しさん：2011/09/08(木) 19:36:24.39

設定画面を見れば一目瞭然だと思うのですが。

145 ：デフォルトの名無しさん：2011/09/08(木) 19:39:44.66

ああ。Notification Centerでしたか。

146 ：デフォルトの名無しさん：2011/09/11(日) 23:41:30.95

最近のCygwinはUTF-8だから日本語も問題が起きないんだよね？

てことはmsysがUTF-8になったらmsysGitでも日本語をUTF-8で使えるようになるの？

147 ：デフォルトの名無しさん：2011/09/12(月) 06:08:02.38

理屈はそうだが、msysはUTF-8にならないだろ。
VC++のランタイムをそのまま使うのがmingw、自前でPOSIX層を用意してるのがCygwinなんだから

148 ：デフォルトの名無しさん：2011/09/13(火) 02:53:48.52

gitにはclearcaseでいうmerge arrowという概念はある？　

149 ：146：2011/09/13(火) 09:56:30.65

>>147
なるほど。そこらの仕組みがよくわかってなくて
Cygwinのパッケージが少ないのがmsys、ぐらいのイメージだった。
そうするとやっぱり日本語は望み薄だな…

150 ：デフォルトの名無しさん：2011/09/13(火) 10:31:53.47

システムロケール変更すりゃいいじゃん

151 ：デフォルトの名無しさん：2011/09/13(火) 22:03:46.41

今日git checkout .を誤爆して数時間の作業がパーになったんだけど、何とかして修復する方法はない?

152 ：デフォルトの名無しさん：2011/09/13(火) 23:10:59.72

>>151
そのファイルを一度もadd してなかったらどうしようもないな。
checkout もclean みたいに-f 必要だね…

153 ：デフォルトの名無しさん：2011/09/14(水) 08:58:57.49

>>151
-f がついてなかったら、未コミットファイルとの競合でチェックアウトは失敗すると思ったんだが…
checkout -f で上書きしちまったんだったら Git レベルでは修復の方法はない、ハズ。

まめに stash するんだなw そうすればオブジェクトは残る。

154 ：デフォルトの名無しさん：2011/09/15(木) 22:00:19.89

リポジトリに残っていないなら
復元ツールを使うとか

155 ：デフォルトの名無しさん：2011/09/19(月) 01:35:03.40

なんかずっとメンテ中になってるな、ダウンロードできん

156 ：デフォルトの名無しさん：2011/09/19(月) 08:10:47.08

>>155
Gitのソースコードのことなら、kernel.orgがハクられて落ちてる
こっちのミラーからダウソ推奨
ttp://ftp.iij.ad.jp/pub/linux/kernel/software/scm/git/?C=M;O=D

157 ：デフォルトの名無しさん：2011/09/19(月) 09:53:36.00

kernel.orgはいつ復活するのかのぅ
いろんな所で影響出てる

158 ：デフォルトの名無しさん：2011/09/20(火) 11:31:20.00

まだ乗っ取られたままだったのか。

159 ：デフォルトの名無しさん：2011/09/20(火) 11:38:10.98

乗っとられたままというか、乗っとられていない状態に戻すのに時間かかってるのだろ

160 ：デフォルトの名無しさん：2011/09/20(火) 12:21:15.89

荒らされる前に戻すのが大変てことか

161 ：デフォルトの名無しさん：2011/09/20(火) 13:17:00.60

子供はじっとしてなさい

162 ：デフォルトの名無しさん：2011/09/21(水) 19:46:00.78

今までずっとCygwinでgit使ってきて、今日初めてLinux上でgit使ってみたら速すぎて吹きました。
Cygwin上での遅さ(リーナスが発狂するレベル)を改善するテクニックみたいなのがあれば教えてください。

163 ：デフォルトの名無しさん：2011/09/21(水) 20:05:09.32

Cygwinはファイル操作が致命的に遅いからねえ。
どうしようもないんじゃないのかな。

164 ：デフォルトの名無しさん：2011/09/21(水) 20:15:49.03

ボトルネックになる場所を特定してその部分だけでもcygwinをバイパスすればマシになるかもね

165 ：デフォルトの名無しさん：2011/09/21(水) 20:20:44.58

莫大なファイルを読み書きするところがネックだと思う
でもそこってメイン処理なんじゃ…

166 ：デフォルトの名無しさん：2011/09/21(水) 22:17:52.69

>>162
cygwin を窓から捨てろ

167 ：デフォルトの名無しさん：2011/09/21(水) 23:03:45.36

>>166
確かにhgの方がWindowsフレンドリーみたいですね…

168 ：デフォルトの名無しさん：2011/09/21(水) 23:46:03.85

Cygwinって、まだサポートされているのかよ？
穴だらけなんじゃね？

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

>>168
Cygwin使っている人いますか？その20
http://hibari.2ch.net/test/read.cgi/unix/1268282846/

170 ：デフォルトの名無しさん：2011/09/22(木) 09:12:31.83

WindowsのForkがクソ重いんだっけ

171 ：デフォルトの名無しさん：2011/09/22(木) 10:03:15.11

forkよりstatの遅さの方が影響してるんでないかなぁ

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

ああ、そういえばgccもcolinux上で動かした方がCygwin/MSYSよか速かったなあ。
そっちでgit試してみます。

173 ：デフォルトの名無しさん：2011/09/22(木) 13:59:13.56

cygwinだとgit遅いのかー
というよりcygwinで開発とかすげーな

174 ：デフォルトの名無しさん：2011/09/22(木) 14:16:06.03

遅いと言ってもネイティブのSVNよりは早いと思った

175 ：デフォルトの名無しさん：2011/09/22(木) 15:16:08.05

Cygwin上で開発してるわけではないです。
Windows上で開発してるものをgitでバージョン管理している、というだけで。
(gccの件は過去の経験上、というだけで)

>>174
確かにそうですね。branchやcommitは即座に完了しますし。
ただgit使ってるとstashやらrebaseやら、
svnでは(機能自体無いので)使わなかった便利機能を使い出すと…という感じですね。

176 ：デフォルトの名無しさん：2011/09/22(木) 16:05:46.13

libgit2がWin32ネイティブ対応していてパスをUTF-8で扱うようになったから
いずれはまともに使えるようになるかもしれない

177 ：デフォルトの名無しさん：2011/09/23(金) 00:11:06.58

なに？なに？今度は期待していいの！？

178 ：デフォルトの名無しさん：2011/09/23(金) 01:33:44.94

現状はかなりカオス気味
VS2008以前でビルド通らないままだったり、
DLLは__stdcallなのにヘッダが__cdeclでリンク不能だったり

179 ：デフォルトの名無しさん：2011/09/25(日) 16:21:45.04

なんかtortoisegitである日から
fatal: bad config value for 'core.hidedotfiles' in ./config
ってメッセージが出てpushに失敗するようになった
なんにもしてないのに。

180 ：デフォルトの名無しさん：2011/09/25(日) 19:01:19.50

おまえ以外の誰かが何かしたんだろ

181 ：デフォルトの名無しさん：2011/09/25(日) 21:22:26.62

この部屋は俺以外いないはずだけど

hideDotFilesって何のパラメータ受け入れてくれるんだよ

182 ：デフォルトの名無しさん：2011/10/01(土) 23:15:32.00

1.7.7ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ttp://article.gmane.org/gmane.comp.version-control.git/182519
> The latest feature release Git 1.7.7 is available.
> The release tarballs are found at:
> http://code.google.com/p/git-core/downloads/list
> and their SHA-1 checksums are:
> bbf85bd767ca6b7e9caa1489bb4ba7ec64e0ab35 git-1.7.7.tar.gz
> 33183db94fd25e001bd8a9fd6696b992f61e28d8 git-htmldocs-1.7.7.tar.gz
> 75d3cceb46f7a46eeb825033dff76af5eb5ea3d9 git-manpages-1.7.7.tar.gz

183 ：デフォルトの名無しさん：2011/10/01(土) 23:18:07.55

今日1.7.6.4をソースからビルドしたばっかなのに・・・

184 ：デフォルトの名無しさん：2011/10/01(土) 23:19:08.62

何が新しくなったの？

185 ：デフォルトの名無しさん：2011/10/02(日) 21:21:14.29

あ…ありのまま今　起こった事を話すぜ！
『newlibのcvsリポジトリをgit cvsimportしたら
1リビジョンだけで7時間もかかったあげくファイルが全部壊れてた』
な…　何を言ってるのか　わからねーと思うが(ry

-rwxr-xr-x 1 user user 41349014 Oct 2 21:16 ChangeLog
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 Makefile.am
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 Makefile.in
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 NEWS
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 README
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 acinclude.m4
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 aclocal.m4
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 configure
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 configure.host
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 configure.in

何故全ファイルの中身が連結されてるの・・・

186 ：デフォルトの名無しさん：2011/10/03(月) 07:02:35.26

よく七時間も粘ったね

187 ：デフォルトの名無しさん：2011/10/03(月) 07:55:02.82

野良構築された newlib.git 探してみては?

188 ：デフォルトの名無しさん：2011/10/03(月) 19:32:50.04

>>186
調べるとあり得ないレベルで遅いって話は聞いてたからでかいリポジトリだしそんなもんだと思ってた
ところが40MB*1500ファイル=60GBも転送していたという(ローカルのcvsミラーだが)

>>187
探したけどリリースのtarballから作ったリポジトリしか見つからなかったんだ
自分の環境に合わせて修正するのが基本のソースだから簡単に見つかると思ったんだけど

189 ：デフォルトの名無しさん：2011/10/03(月) 22:24:08.99

git cvsimport　はインポート後の履歴が変だったことがあったから使ってないな
代わりに cvs2git 使ってる。インクリメンタルインポートできないのが難点だが

190 ：デフォルトの名無しさん：2011/10/04(火) 22:14:45.01

え？BitBucketもGitに対応したの
Bitbucket now rocks Git ? Bitbucket blog http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git/

191 ：忍法帖【Lv=32,xxxPT】：2011/10/04(火) 22:15:59.59

対応したと聞いて昼過ぎに登録してきたｗｗ

192 ：デフォルトの名無しさん：2011/10/05(水) 00:58:00.16

GitHub と比較してどうなの？

193 ：デフォルトの名無しさん：2011/10/05(水) 05:11:58.79

最近 Github が人気になりすぎたのか重くてしょうがない。
Buildbot のソースに使うのもはばかられてきた。

194 ：やんやん ◆yanyan72E. ：2011/10/05(水) 08:00:53.58

自分の鯖か知人の鯖でgitosisにするのが吉

195 ：デフォルトの名無しさん：2011/10/05(水) 09:55:55.19

gitosisって2年くらい前で更新止まってなかったか
ほぼ上位互換で更新も続いてるgitoliteのほうがいいだろ

196 ：デフォルトの名無しさん：2011/10/05(水) 19:47:52.13

gitolite なんてファイルサーバにレポジトリを直置きするのとあんま変わんないじゃん
Gitorious のほうがいいって

197 ：デフォルトの名無しさん：2011/10/05(水) 19:52:58.80

>>190
クエスチョンなんか付けてるからrumorかとおもた

198 ：190：2011/10/05(水) 21:49:32.90

>>197
ChromeのCreate Link拡張使ったらそうなった。
書きこむ前はついていなかったのに、-が?に変化した

199 ：デフォルトの名無しさん：2011/10/05(水) 23:02:01.15

ギトギトしたスレだなぁ

200 ：やんやん ◆yanyan72E. ：2011/10/06(木) 11:00:38.55

ほんとだ。gitosisって相当古いのね。暇を見つけてGitoriousに移行します。

201 ：デフォルトの名無しさん：2011/10/06(木) 12:53:07.12

Gitorious のインストールは手間がかかるから
丸一日くらい費やされると思っといたほうがいい

202 ：デフォルトの名無しさん：2011/10/07(金) 20:11:12.58

ディレクトリ単位でプロジェクトを分けたい（一つのリポジトリに複数プロジェクトをいれたい）
のですが、そういうことはしない方がいいですか？

203 ：デフォルトの名無しさん：2011/10/07(金) 20:22:05.15

いいです

204 ：デフォルトの名無しさん：2011/10/07(金) 20:27:43.80

AというプロジェクトとBというプロジェクトとCというプロジェクトに関連性を持たせたいなあと考えたことはある
現行では素直にディレクトリ分ける以外に方法がないわけだが

205 ：デフォルトの名無しさん：2011/10/07(金) 20:40:43.82

そうですか
ありがとうございました

206 ：デフォルトの名無しさん：2011/10/07(金) 22:13:56.81

submodule?

207 ：デフォルトの名無しさん：2011/10/08(土) 13:04:33.00

すみません。とても基本的なことですが、
bashにて、git blame を実行すると、末尾に(END)が出てきて入力を受け付けず
抜けられない状態に陥ります。
ここから抜ける方法を教えてください。

208 ：デフォルトの名無しさん：2011/10/08(土) 13:23:25.75

PAGERがlessなのかね?

q

209 ：デフォルトの名無しさん：2011/10/08(土) 14:28:37.87

revertは変更をアンドゥしているのではなく、中身は以前の状態にしているけど履歴的にはさらに新しい
変更をした状態にするってことでしょうか？

210 ：デフォルトの名無しさん：2011/10/08(土) 14:46:40.72

>>209
だいたい合ってるけど、「中身を以前の状態に」はしない。
逆方向のパッチを当てるだけ。なのでrevertで指定した
コミットとHEADの間にコミットがある場合は「元に」は
戻らない。

211 ：デフォルトの名無しさん：2011/10/08(土) 16:18:45.58

>>210
結果的に同じ tree を指すことになるのが常。

212 ：デフォルトの名無しさん：2011/10/09(日) 00:07:56.19

>>211
半年前のコミットをrevertしたと考えてみよう

213 ：デフォルトの名無しさん：2011/10/09(日) 01:47:12.53

git push した先のサーバー内の、
ログやデータを一部削除するためのgitコマンドを教えろ

コピペしてすぐ使えるような具体的なコマンドで説明よろ

214 ：デフォルトの名無しさん：2011/10/09(日) 01:52:09.01

>>213
ねーよカス
ガキは糞して寝ろ

215 ：デフォルトの名無しさん：2011/10/09(日) 02:17:10.09

>>213
ssh rm -fr /

216 ：デフォルトの名無しさん：2011/10/09(日) 02:25:54.68

>>215
サンクス！
さっそくパクらせてもらうわ！ザマー！！！！ｗｗｗｗｗｗ

217 ：デフォルトの名無しさん：2011/10/09(日) 02:41:49.73

おやすみ

218 ：デフォルトの名無しさん：2011/10/09(日) 03:04:06.38

おまわりさんこいつです！

219 ：デフォルトの名無しさん：2011/10/09(日) 08:08:07.92

Gitで管理しているディレクトリを動かしても問題は起きませんか？
たとえばhome/mysite/以下のディレクトリを管理している状態で（home/mysite/.git/ディレクトリがある状態で）
mysite/以下をdoc/ディレクトリに移動させたり、
mysite/ディレクトリそのものをmysite8/にリネームしたりしても。

220 ：デフォルトの名無しさん：2011/10/09(日) 08:12:22.98

大丈夫

221 ：デフォルトの名無しさん：2011/10/09(日) 11:06:42.49

sudo を入れないとこが良心的? まあ sudoer のわけないか。

222 ：デフォルトの名無しさん：2011/10/09(日) 14:28:11.33

その前にホスト名

223 ：デフォルトの名無しさん：2011/10/09(日) 14:48:44.32

git cloneをしたところ、以下のエラーが出ました。

fatal: internal error: work tree has already been vital
Current worktree: /home/mysite2
New worktree: /home/mysite2/test/

このエラーは何が原因でどうすれば回避できますか？

224 ：デフォルトの名無しさん：2011/10/09(日) 14:50:17.90

間違い。以下でした。
fatal: internal error: work tree has already been set
Current worktree: /home/mysite2
New worktree: /home/mysite2/test/

225 ：デフォルトの名無しさん：2011/10/09(日) 16:08:17.20

すでにカレントディレクトリよりも上のディレクトリがgitの管理下になっているときには
下層のディレクトリをgit initすることはできないのですが、これはどうしてもそうなのでしょうか？

226 ：デフォルトの名無しさん：2011/10/09(日) 17:37:47.22

俺はホームディレクトリの .git でドットファイルを管理しつつ、
ホームディレクトリのなかにもいろいろ独立したgitリポジトリがあるんだが。

227 ：デフォルトの名無しさん：2011/10/09(日) 21:29:22.17

cvsとsvnは使ったことがあってgitは使ったこと無いんですが
gitに乗り換えた方が便利なんですかね
svnの次世代バージョンみたいな認識で合ってるんですかね

228 ：デフォルトの名無しさん：2011/10/09(日) 22:01:15.24

svnで何も困っていないなら無理に乗りかえなくてもいいと思う

229 ：デフォルトの名無しさん：2011/10/09(日) 22:23:14.54

とりあえず入門gitという本で一通り勉強してみたが
いまいちgitの良さが分かんないな
ステージという概念も単に冗長で面倒くさいだけとしか思えないし
分散バージョン管理システムと言いつつも結局複数人で開発するときは
リモートリポジトリ？を作って集中型のバージョン管理するわけだよね
リーナスという人の自己顕示欲を満たすためだけに作られた
ソフトウェアなんじゃないのと言ったら言いすぎだろうか

230 ：デフォルトの名無しさん：2011/10/09(日) 22:28:06.80

リポジトリ1本で全く困らないような開発体制＆思考体系なら集中型で過不足無いだろうし、
GUIから使うなら.svnが散らばっててもさほど困らないしステージングも冗長かもしれない。

231 ：デフォルトの名無しさん：2011/10/09(日) 22:35:25.93

GitHubを使えるのが大きな利点だと思うぞ。

232 ：デフォルトの名無しさん：2011/10/09(日) 22:53:11.19

svnで満足してるならsvn使ってればいいじゃないか

233 ：デフォルトの名無しさん：2011/10/09(日) 22:53:19.09

ある程度のプロジェクトの規模が大きくないと恩恵少ないかもね
ソースがプログラマ一人の脳みそで足る量を超えたあたりから便利になるかも

234 ：デフォルトの名無しさん：2011/10/09(日) 23:00:13.93

それはsvnでは駄目でgitでしか解決できないことなん

235 ：デフォルトの名無しさん：2011/10/09(日) 23:15:52.92

どうせ一回のコミットごとに申請書提出するような職場なんでしょ？
だったらsvnでいいよ

236 ：デフォルトの名無しさん：2011/10/09(日) 23:27:00.92

良く分からんがgitでリモートリポジトリにコミットするのと
svnでサーバーにコミットするのとは同じことじゃないの？
gitの方がコミット前にステージングという良く分からん手順が必要なだけで

237 ：デフォルトの名無しさん：2011/10/10(月) 00:17:55.94

add -p とか rebase -i とかやらないとgitのうれしさは分からん。

238 ：デフォルトの名無しさん：2011/10/10(月) 02:17:42.78

>>236
そのよく分からない部分を分かるようになるまで勉強するんだ

239 ：デフォルトの名無しさん：2011/10/10(月) 03:49:00.09

なんであるものxの良さがわからないと、
xなんて作ったやつの自己顕示だとかこき下ろしたりするんだ?
おまえがxのことを理解できなくても誰もバカになんかしてないぞ

240 ：デフォルトの名無しさん：2011/10/10(月) 04:07:53.26

ローカルにブランチが持ってこれるというのは俺にとって革命的だった

241 ：デフォルトの名無しさん：2011/10/10(月) 07:25:34.26

ローカルコミットできる便利さはよくわかるが
これによって発生する運用上の課題が
容易に容易に想像できるので気軽に
仕事で使う気にはなれないな。

手元のごみコミットを整理せずに
pushして中央の履歴がカオスとか、
ローカルコミットしただけで
push忘れて反映されないとか、
何週間もローカルで作業して
成果を見せない奴がててくるとか、

どうやって解決してるの？
全員がスキルの高いチームでしか使えない？

242 ：デフォルトの名無しさん：2011/10/10(月) 07:37:59.60

>>241
いい加減スレ違い。こっちでやれ。
バージョン管理システムについて語るスレ8 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1295493964/

それは全てSVNでも言えること。
GitなどVCSはツールに過ぎない。
コミュニケーション手段は別。

243 ：デフォルトの名無しさん：2011/10/10(月) 07:39:12.71

git branch a
git checkout a
でコード修正作業用のブランチに移動する。

このブランチ内で、各ソースファイルを修正して、適当に数行～数十行修正する度に
git commit -a -m"適当な名前"
でコミットしてしまう。

この段階は試行錯誤の段階なので、数手前に戻りたい場合も出てくる、
その場合は
git log 修正してたファイル名　　　　　　　　　　// 修正してたファイルの関連してるコミットの一覧を表示する
git diff 12345678 修正してたファイル名 > p　　　// 戻りたい位置との差分パッチを得る。　12345678 はコミットIDの例
patch -R < p　　　　　　　　　　　　　　　　// パッチを充てて、ファイル状態を修正前に戻す

ひと通り、コード修正が終わったとして、そのコミットログはコメントも適当だし、試行錯誤の後も残ってて汚れてるので、
master との比較で最終結果を一つのパッチにまとめる。
git diff master > p

このパッチをmasterに充てる。
git checkout master
patch < p
git commit -a -m"正式なコミットコメント"

作業中の試行錯誤をgitを活用しながら進めることができ、最終的な修正結果は一つのパッチにまとめてコミットを綺麗な状態で行える。
もちろんパッチを綺麗にしようとしなければ、汚いログのままコミットしてもいいし、作業中の手戻りにgitを使わず古典的なバックアップファイルで行ってもいい。
ステージは、パッチを意味のあるまとまり毎に分けてコミットするためのもの。全部ひとまとめにコミットしてもいい場合は必要ない作業。
gitだと、修正範囲の狭いシンプルな複数のパッチが好まれる。様々な修正が含まれたごった煮パッチ１個にまとめてコミットすると嫌がられる。

244 ：デフォルトの名無しさん：2011/10/10(月) 08:14:21.35

>>まちがえたpushで中央の履歴がカオス
そうなる前との差分をコミットして、その段階までリセットしてやりなおせばいい。

>>push忘れで反映されない
普通はコード修正が完了したら、まっさきにpushしたいと思うはず。
もたもたしてると他人の修正とのバッティングで面倒に成りかねない。

>>何週間もローカルで秘密的に作業する奴
作業量が増えて損をするだけ。
他の人は、この人の秘密作業の修正コードを知らずに、各自が勝手に作業を進めて、中央（的な役割と決められた場所）へとコミットしてしまう。

中央との差は、中央に公開してしまえば、他の人も、その差を無くすように作業してコミットするが、
中央に公開しないままならば、他の人は、その差を考慮せずにコミットしてしまう。

秘密的に非公開で作業し続ければ、この差を修正する作業を、（本来各自に任せられてた作業をわざわざ）一人で請け負うことになる。
これは明らかに損。
ローカルで秘密的に作業する時間が長ければ長いほど、中央との差は広がり、差を埋める作業という労力が増す。

245 ：デフォルトの名無しさん：2011/10/10(月) 08:22:36.63

gitはsvnを面倒臭くした集中型バージョン管理システム

246 ：デフォルトの名無しさん：2011/10/10(月) 08:32:39.02

なんでこんなに中央を直接更新するのを恐れてるのか分からない
別にコミットミスしてもその旨をコミットメッセージに書いて元に戻せばいいだけじゃねえの
ローカルとリモートで２重管理して生産性落ちるだけじゃねえの
git使ったら開発期間が延びてコスト増大で会社が倒産するわｗ

247 ：デフォルトの名無しさん：2011/10/10(月) 08:36:45.47

君がsvnに慣れ親しみすぎて他に移りたくないという気持ちはよく分かった。
実際に日本の会社ではsvnを使ってるだけでも褒められるレベル。
VCSすら使ってない会社はごまんとある。

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

ごまんはねぇよ。

249 ：デフォルトの名無しさん：2011/10/10(月) 08:39:19.68

gitのスレでsvnの宣伝にきたのかこの人は

250 ：デフォルトの名無しさん：2011/10/10(月) 08:47:53.21

なんだ、最近はgitスレにまでドカタが湧いてんのか

251 ：デフォルトの名無しさん：2011/10/10(月) 08:50:21.16

>>246
君が想定/経験している規模の開発だとミスがそんなに大した問題にはならないのかもしれない。
ローカルとリモートで2重管理しているように感じる体制だと確かに面倒に感じるかもしれない。

252 ：デフォルトの名無しさん：2011/10/10(月) 09:05:23.07

>>242
視野の狭いやつだなw

253 ：デフォルトの名無しさん：2011/10/10(月) 09:17:48.90

>>243
patch 何て使わずに rebase -i でいいだろ

254 ：デフォルトの名無しさん：2011/10/10(月) 10:37:42.73

remoteに行く前のコミットはいじりまくって良いということに慣れないとな

255 ：デフォルトの名無しさん：2011/10/10(月) 10:47:07.29

むしろremoteにぐちゃぐちゃコミット送る人なんなのローカルの概念ないの

256 ：デフォルトの名無しさん：2011/10/10(月) 11:55:58.23

git reset --soft HEAD^は、なぜHEAD^なのでしょう？
今の状態をとりやめたいからHEADでいいんじゃないでしょうか？

257 ：デフォルトの名無しさん：2011/10/10(月) 11:58:51.44

>>246
試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
まあそう考えないということは履歴なんか見ないんだろうがね。

258 ：デフォルトの名無しさん：2011/10/10(月) 11:58:55.95

HEADから一つ戻すからHEAD^なんだろ

259 ：デフォルトの名無しさん：2011/10/10(月) 12:20:12.89

テスト済みのコードに変更を加えていく場合とかで、レビュー済みのもののみを
履歴に残す形式で開発する状態になるとgitのスタイルがしっくりくる。
テスト済みなのにぐちゃぐちゃ変な変更が入っていくようなことをやる会社は倒産する。

260 ：241：2011/10/10(月) 12:21:40.40

>>243-244 ありがとう
> 作業中の試行錯誤をgitを活用しながら進めることができ、最終的な修正結果は一つのパッチにまとめてコミットを綺麗な状態で行える。

> >>まちがえたpushで中央の履歴がカオス
> そうなる前との差分をコミットして、その段階までリセットしてやりなおせばいい。

「間違えたpush」ではなくて、「試行錯誤の途中経過を含んだコミット」を別のメンバーがpushしまくる。
で履歴にこだわる俺が「なんでこんなもんremoteにpushするんだよ。馬鹿なの死ぬの？」とイライラする絵が浮かぶ。
もちろん日に(svn基準)数10コミットはあるのでいちいち誰かが修正するのなんか無理。

> >>push忘れで反映されない
> 普通はコード修正が完了したら、まっさきにpushしたいと思うはず。
> もたもたしてると他人の修正とのバッティングで面倒に成りかねない。

なるほどね。この辺の心理はGitで共同作業してないからわからなかった。

導入時のガイドラインとして、svnで意味のある単位でのコミットができていれば、
svnのcommitとgitのcommit(同時にpush)を同じぐらいの粒度ですればいいのではないかと思った。
よく考えたら試行錯誤中のこまめなコミットなんかするわけないしな。

> >>何週間もローカルで秘密的に作業する奴
> 作業量が増えて損をするだけ。
> 秘密的に非公開で作業し続ければ、この差を修正する作業を、（本来各自に任せられてた作業をわざわざ）一人で請け負うことになる。

もちろんそのとおりなんだが、
こういうのは「マージに時間がかかって遅れました」と平気で人事にするからな・・・
これは明らかに人の問題だから啓蒙するしかないか。

261 ：デフォルトの名無しさん：2011/10/10(月) 12:26:56.93

結論としてはgitは不要ということだな
あれだろsvnと同じもの作ったらパクッたって言われるから
変な機能付けてオリジナルの画期的なソフトウェアができたとか主張してるんだろｗ

262 ：デフォルトの名無しさん：2011/10/10(月) 12:31:00.91

svnみたいなウンコで満足出来るならDVCSいらない

263 ：デフォルトの名無しさん：2011/10/10(月) 12:36:19.70

git reset --hard HEAD^で取り消したコミットに再び行き着くには、
git reflogでコミット一覧を表示して調べるしかありませんか？

264 ：デフォルトの名無しさん：2011/10/10(月) 12:44:02.79

svnとgitが同じに見えるならお前の目は不要だな

265 ：デフォルトの名無しさん：2011/10/10(月) 12:45:13.91

そんなにsvnが好きならalias使ってgitのコマンドをsvnライクにすればいいよ

266 ：デフォルトの名無しさん：2011/10/10(月) 12:45:30.33

>>263
だね。しかも--hardしてるってことは、addしてなかったファイルはもう手に入らない。。。

267 ：241：2011/10/10(月) 12:47:55.40

>>257
> 試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
> まあそう考えないということは履歴なんか見ないんだろうがね。

コミットを気軽にできるGitの方がむしろ「試行錯誤だらけのイミフな変更」が
remoteに入りやすいんじゃないの？
そうならないためにはpushする前にpushする人が整理しないといけないんだよね。
正直、机上で考えてるだけだといい解決策が思い浮かばない。

「いずれ公開されるから、後で整理するのが嫌なら中途半端なコミットはするな」
「gitの便利さを享受したければpushの前に整理しろ」
という運用ルールにすればいいのかな

268 ：デフォルトの名無しさん：2011/10/10(月) 12:51:45.59

中途半端なコミットなんかsvnでもgitでもありえるわけで
git使ったら解決されるわけでもないわけで
ステージングとかいうイミフな仕組みに工数とられるgitはうんこ

269 ：デフォルトの名無しさん：2011/10/10(月) 12:55:28.32

大体みんなで共有する中央リポジトリが存在する時点で集中型システムだろ
分散型とか言うから中央リポジトリなくてp2pみたいに開発者同士でネットワーク張ったりするのかと思ったのに
ただの面倒な２重管理だもんな糞ゲーだろ

270 ：デフォルトの名無しさん：2011/10/10(月) 13:01:20.54

>>267
Gitは「後で整理する」のが容易なようになってるから後で整理するのも良し、
add -p で最初から良い感じのコミット組み上げていっても良し。公開前は個人の裁量。

ただし、プロジェクトの運営ルールは柔軟に決めればいい。超々タイトなスケジュールを
複数人でやっつけるなら奇麗なコミット云々言ってられないだろうし、その状況では
頻繁な公開=中途半端なコミットのpushが必要になる。
その後のリリースの段階ではやはりそういう履歴は不要になるから、いったんsquashなり
するかも知れない。雑だけど有用な履歴だと判断したらそのままにするかも知れない。

271 ：デフォルトの名無しさん：2011/10/10(月) 13:04:47.64

>>269
「中央」リポジトリなどGitには無い。使う人がそう決めつけるだけだ。
無知でかわいそうなヤツ。

272 ：デフォルトの名無しさん：2011/10/10(月) 13:09:42.02

無くたって現実には作るだろうよ・・・頭の固いやつだな

273 ：デフォルトの名無しさん：2011/10/10(月) 13:15:35.77

中央リポジトリがないってことはリリース時はどこから成果物を取り出すの？
成果物を取り出してる場所が中央リポジトリじゃないの

274 ：デフォルトの名無しさん：2011/10/10(月) 13:23:09.04

「gitイラネsvnでいい」と個人的に思ってるならまだしも
まわりにそれを押し付けるバカの多いこと

275 ：デフォルトの名無しさん：2011/10/10(月) 13:25:33.66

じゃあgitの良いところを教えてくれよ良いものは取り入れたいんだよ
２４００円も出して入門git買ってきたのにうんこ掴まされたんじゃ愚痴も言いたくなるよ

276 ：デフォルトの名無しさん：2011/10/10(月) 13:28:48.27

>>273
分散型やるならまず概念を変えないと先には進めないぜ
成果物は好きに取り出せ
中央だと思う場所があるなら、そこがお前にとっての中央かもしれんね

277 ：デフォルトの名無しさん：2011/10/10(月) 13:29:12.09

「入門Git」がうんこの一言で片付けられたらどうやってGitのいいところを伝えればいいんだよ…
DVCSをいかにして使うかよくわかる名著なのに

278 ：デフォルトの名無しさん：2011/10/10(月) 13:31:02.33

入門gitにうんこついてたのか
交換してもらえよ

279 ：デフォルトの名無しさん：2011/10/10(月) 13:35:34.86

リビジョン番号も意味不明な文字列になってるし
過去のある時点にソフトウェアの状態を合わせたいときに
意思疎通しにくいだろ

280 ：デフォルトの名無しさん：2011/10/10(月) 13:38:35.42

リビジョン番号（笑）

分散してるのに採番とかしねーよ

281 ：デフォルトの名無しさん：2011/10/10(月) 13:39:31.58

svn信者はアホってことが良くわかるな

282 ：デフォルトの名無しさん：2011/10/10(月) 13:46:04.52

>>268
svnで中途半端なコミットなんかありえねーよ。
おめーtrunkのビルドこけさせたら死んで詫びろ。いいかわかったな

283 ：デフォルトの名無しさん：2011/10/10(月) 13:51:11.94

　　　　　　　　＿_
　　　　 , ‐' ´　　　｀`‐、　　　　　　／￣:三}
.　　　／,. -─‐- ､.　　ヽ　　　　　　　　/　　 ,.＝j
　＿,.:_'＿＿＿＿＿_ヽ、　.!　　　　　 .／　 _,ﾉ
　 `‐、{　へ　　'ﾞ⌒　`!~ヽ. !　　　　／{.　　/
　　　｀!　しﾟ　（　ﾟj　`v‐冫　　　, '::::::::ヽ､/ 　　　　そんなことよりBazaarしようぜ！
.　　　 {.l 　 '⌒　　　ﾞ 6',!　　 / :::::::::::::::/ __
. 　　〈　　< ´￣,ﾌ　 .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
.　　　ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠.　　ヽ_}　ﾞヽ
　　　　 ,.r｀ "´　　／:::::::::::::::::::ィ´　　｀ゝ　 !、　　/
　　　　　/ 　　　 / :::::::::::::::: ; '´　　　/´＼　/ 　 r'＼
.　　　　 i　　　　　 ! ::::::::::::::／墨　|　.!::::::::／ヽ､.._!ヽ.　ヽ､
　　　　 {　　　　　 {:::::::::::;:ｲ　/　　 ∥ｉ:::::::/:::::::::::::/　＼
.　　　ヽ　　　ヽ,.ｧ‐'´ /ヽ二 ,/`ヽ、::::::::: ／

284 ：デフォルトの名無しさん：2011/10/10(月) 14:25:09.84

結局、gitを使うと、svnで培ったオレ流を他の奴が守ってくれないかも
しれないから嫌だ。っていう文句しか言ってないのね。
どうせsvn使ったってオレ流を人に押しつけてるだけだから
うまくいかないのに、それをDVCSのせいにされてもねぇ。

svnでできることはgitでもできる。
gitでは他の便利なことや柔軟な運用もできる。
それでも最終的な成果物のコミットのポリシーをどうするかは
属人的な問題で人と人の意思の疎通でしか解決できない。

VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ
いずれプロジェクトは滅茶苦茶になるさ。
それはDVCSのせいじゃない。

285 ：デフォルトの名無しさん：2011/10/10(月) 14:25:19.69

富士通ではVCSすら使ってなかったなあ
大きなプロジェクトはPerforce使ってたけど
git使ったら他には戻れないと個人的に思うなあ

286 ：デフォルトの名無しさん：2011/10/10(月) 14:27:08.02

ちょっと履歴を遡りたいときにはgit reset HEAD^^よりもgit commit HEAD^^の方がいいかな？

287 ：デフォルトの名無しさん：2011/10/10(月) 14:27:49.60

煽ってんじゃねえよてめえ

288 ：デフォルトの名無しさん：2011/10/10(月) 14:34:20.57

>>286
git checkoutだろ

289 ：デフォルトの名無しさん：2011/10/10(月) 14:36:12.50

そうだった。checkout

290 ：デフォルトの名無しさん：2011/10/10(月) 17:35:25.24

ギットギトのgit

291 ：デフォルトの名無しさん：2011/10/10(月) 19:06:37.78

>>256
よく分からんが今の状態を取りやめたいなら
git reset
でいいんじゃね？

292 ：デフォルトの名無しさん：2011/10/10(月) 19:21:26.54

ポインタにNULLを入れて
何回でもギットギトにしてやる

293 ：241：2011/10/11(火) 09:24:33.37

もしかして俺が煽られてるのかなw

>>284
>svnでできることはgitでもできる。
>gitでは他の便利なことや柔軟な運用もできる。
>それでも最終的な成果物のコミットのポリシーをどうするかは
>属人的な問題で人と人の意思の疎通でしか解決できない。

だからそのポリシーをどうすればsvnを使ってるチームが移行しやすいか、
という話なんだが。
運用上svnから劣化する点があれば対策を考えるよね。
運用ルールでなんとかできるのか、どうしようもないのか。
自由度が高いならなおさら「gitにしました。あとは好きにしろ」じゃ
回らないよね

>VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ

svn使ってたらsvn利用を前提にプロセスを最適化するのは当然だろ

294 ：デフォルトの名無しさん：2011/10/11(火) 09:28:46.16

>>293
> 運用上svnから劣化する点があれば対策を考えるよね。
？？？？？？？？？？？？

295 ：デフォルトの名無しさん：2011/10/11(火) 10:19:13.55

とりあえずオープンソースで今時svn使ってるプロジェクトはうんこ
パッチ書いて送ったら「tortoise diffじゃないとヤダヤダ」とかぬかすような連中ばっかり

296 ：デフォルトの名無しさん：2011/10/11(火) 10:21:50.23

パッチとか面倒なこと考えずに直接更新すればいいだろ

297 ：284：2011/10/11(火) 12:50:03.08

>>293
あなたを煽ったつもりはないです。
自分のプロジェクトはsvnが合ってるからsvnを使うよというだけの人を
どうこういうつもりはまったくないので。
VCS使わないって選択肢もありだと考えますし。

ただ、そのことをもって、
gitそのものをdisるキチガイが湧いていたので、
それに反論したのみです。

298 ：デフォルトの名無しさん：2011/10/11(火) 12:52:01.85

gitは無駄に２重管理する生産性の低いうんこだし
git使って開発してるやつはもっとうんこです

299 ：デフォルトの名無しさん：2011/10/11(火) 12:59:21.60

２重管理厨しつこい

300 ：デフォルトの名無しさん：2011/10/11(火) 13:01:49.61

かかってこいよ

301 ：デフォルトの名無しさん：2011/10/11(火) 13:04:10.15

何をやりたいのか分からないな。
svnを褒め称えてgitをdisればみんながgitを放棄してsvnへ流れてくれるとでも思っているのだろうか。

302 ：デフォルトの名無しさん：2011/10/11(火) 13:43:29.39

２重管理地獄の中で悶えて死ね！！！

303 ：デフォルトの名無しさん：2011/10/11(火) 17:40:00.81

2重管理したくないやつは、しなきゃいいんじゃね？

304 ：デフォルトの名無しさん：2011/10/11(火) 17:50:07.41

何が２重管理なのか理解できないのだが

305 ：デフォルトの名無しさん：2011/10/11(火) 19:31:02.34

2重管理って何?

306 ：デフォルトの名無しさん：2011/10/11(火) 19:41:48.17

派遣先用と自社用に２枚勤務管理表を書かないといけないだろ？

307 ：デフォルトの名無しさん：2011/10/11(火) 20:07:51.85

>>293
svnでの運用ルールが破綻してgitに乗り換えようとしたが
gitが難解でgitに八つ当たりしているのですね？

308 ：デフォルトの名無しさん：2011/10/11(火) 20:35:54.93

二重管理最高だろ。
svnのコミットするのに申請書が必要な環境では
ローカルリポジトリと共有フォルダ内work内のbareリポジトリで
実質的な管理をするもんなんだよ

309 ：デフォルトの名無しさん：2011/10/11(火) 20:56:01.10

２重管理求められる環境とか経験ないんだけど申請書？とか必要ない環境だったら２重管理のメリットなんか何もないってことだよね？
２重管理とかマージするときに競合が起きた場合の面倒臭さがより増大するだけじゃないの

310 ：デフォルトの名無しさん：2011/10/11(火) 21:00:21.90

なるほど、svnのマージを使ったことが無かったのか

311 ：デフォルトの名無しさん：2011/10/11(火) 21:04:23.49

むしろsvnしか使った事が無いから、必要以上に競合を恐れてるのでは？

312 ：デフォルトの名無しさん：2011/10/11(火) 21:49:49.44

マスターリポジトリと各開発者のローカルファイルがリアルタイムで同期していない以上、
svnもgitも多重管理していることに違いは無いと思うけど。その言い方を真似ると。

その上で、君はsvnでは多重管理している意識が無いと言っているわけだけど
同様にgit使ってる人も多重管理してる意識は無いよ。

ローカルコミットは自分の完全支配下にあるブランチ、とでも考えれば理解しやすい？
(あ、svnでブランチ切るのも多重管理だね。trunkしか使ってないってことはないよね？)
svnだと開発者の誰もが好き勝手ブランチ切ったりできないでしょ。不便じゃない？

313 ：デフォルトの名無しさん：2011/10/11(火) 21:49:55.07

使ったこと無いのに批判してるように見えるなあ
とりあえず社内がsvn使っててもローカルフォルダだけgitで運用する事もできるし
挫折しないで一通り試してみ

314 ：デフォルトの名無しさん：2011/10/11(火) 22:34:11.38

Linux開発向けに大人数でバザール的に作業すること目指してるのが
社内数人のチームで完全に設計してから実装するみたいな用途には
オーバーエンジニアリングに感じるのかも。

パッチ書こうとしてるOSSのリポジトリがsvnだとがっかりするけど
職場のリポジトリがsvnでも若干の不便しか感じない。

315 ：デフォルトの名無しさん：2011/10/11(火) 23:28:41.20

svn もまともに使えないのに git は無理だろう
と、思うことはある
バージョン管理は二の次だったりする所もあるからなあ
レベルは決して低くない所だが

316 ：284：2011/10/11(火) 23:49:37.35

>>293 はまともなsvn使いがgitへの移行を検討するに当たって
gitの実運用上の問題を挙げてるにすぎないんだから、
これ以上煽ってやるな、真面目っぽいからかわいそうだ。

317 ：デフォルトの名無しさん：2011/10/12(水) 00:04:26.67

いや、svnのコンフリクトを防ぐために運用ルールを定めているのであれば、それはツールに使われている。
欠陥ツールであるsvnを破棄してgitに移行すべきであろう。

318 ：デフォルトの名無しさん：2011/10/12(水) 00:05:01.21

俺には>>298とか>>309への反論に見えるな

素人考えでもマージするときの面倒さはsvnもgitも変わらないように思えるんだが

319 ：デフォルトの名無しさん：2011/10/12(水) 00:41:17.03

マージ作業自体の手間はかかるにしても一旦コミットしてからマージできるから
リモートにブランチつくったりローカルの変更を手で保存したりしなくても
変更が失われないってのは結構な利点じゃない？

320 ：デフォルトの名無しさん：2011/10/12(水) 08:00:56.75

gitはTortoiseGitとmsysgitの２重管理のうんこ

321 ：デフォルトの名無しさん：2011/10/12(水) 08:33:09.15

tortoisegit がうんこだったのは同意。ログ見るときと日本語で commit message 書くときくらいしか使ってなかった。
入れ替えるモチベーションなくしてんだが、最近のはどーなんだろ?

もう msysgit のコマンドラインで十分になっちゃってるしなー。

ところでロック厨がわいてくるだろうと蒸し返すw

322 ：デフォルトの名無しさん：2011/10/12(水) 08:54:23.81

>>320
2重管理という用語を使ってる君自身がその用語をちゃんと定義しきれていない気がするよ。
もうちょっと正確に言ってもらわないと、君が疑問に思っていることがあっても残念ながら中々答えてあげられない。

323 ：デフォルトの名無しさん：2011/10/12(水) 09:05:20.36

意味もわからない覚え立ての言葉を使いたい小学生なんだろ

324 ：デフォルトの名無しさん：2011/10/12(水) 09:26:45.65

すぐうんこ言うしな

325 ：デフォルトの名無しさん：2011/10/12(水) 11:13:59.02

ローカルにコミットするメリットがさっぱり分からん

326 ：デフォルトの名無しさん：2011/10/12(水) 11:20:47.64

>>325
ここgitのスレだからそういう一般的な話はこっちで聞いた方が良いよ。
バージョン管理システムについて語るスレ8
http://hibari.2ch.net/test/read.cgi/tech/1295493964/

327 ：デフォルトの名無しさん：2011/10/12(水) 11:51:08.17

いやローカルにコミットできることを分散型だと言ってgitの長所だと主張してんだろ？
そこは納得いく説明をしてくれないと

328 ：デフォルトの名無しさん：2011/10/12(水) 11:53:58.13

回線が切れてても大丈夫。
履歴を好き勝手編集しても大丈夫。
パスワードなどの個人情報を入れた状態でcomitするなどの事故を減らせる。

329 ：デフォルトの名無しさん：2011/10/12(水) 13:15:20.42

ローカルコミットの何が嬉しいの？って言う時点で分散型を
必要としてないよ。どうせマンドクセーってぎゃーぎゃー言うだけ。

330 ：デフォルトの名無しさん：2011/10/12(水) 13:20:25.71

回線が切れてても中央のリポジトリから最新版を取ってきたりコミットできるの
履歴を簡単に書き換えられて過去のある版を取り出したくなったときとか困らないの
事故を減らせる代わりに面倒臭くなってるよね

331 ：デフォルトの名無しさん：2011/10/12(水) 14:03:05.74

>>327
gitだけの特徴じゃないんだよ。

332 ：デフォルトの名無しさん：2011/10/12(水) 14:03:16.03

>>330
履歴の書き換えはローカルだけだから無問題
タグが何のためにあるのか考えよう
タグを見るためにいちいちsvn listコマンドなどを叩いてリモートに見に行く方ががよっぽど面倒

333 ：デフォルトの名無しさん：2011/10/12(水) 14:07:09.37

>>331
svk

334 ：デフォルトの名無しさん：2011/10/12(水) 14:32:19.88

回線が切れてたらさすがにリモートの最新版は取ってこれないが、log,diff,(ローカルに現存してるコミット間での)mergeなんかは使える
というかリモートリポジトリを必要とするpull/push以外の全機能が使えるしそういうコマンドはもともと通信しない

335 ：デフォルトの名無しさん：2011/10/12(水) 14:40:32.34

リモートを書き換えないなら何もしてないのと一緒じゃん
ローカルのものをいきなり成果物として客にリリースしたりするの

336 ：デフォルトの名無しさん：2011/10/12(水) 14:43:33.10

プログラミングにおいて一切の試行錯誤をしないのか？

ああ、与えられた仕様書をコードに起こすだけのコーダなのか
gitはそういうコーダのためのツールじゃないから

337 ：デフォルトの名無しさん：2011/10/12(水) 14:45:06.48

回線切れてるならsvnだろうがgitだろうが手旗信号でも使わないかぎりリモートと通信できるはずないだろｗ

338 ：デフォルトの名無しさん：2011/10/12(水) 14:46:05.37

ローカルでコミットなんかしなくても試行錯誤はできるだろ

339 ：デフォルトの名無しさん：2011/10/12(水) 14:48:00.16

試行錯誤をどうやって管理すんの？
log見たり複数の試行錯誤のdiffとったりmergeしたりせんの？

340 ：デフォルトの名無しさん：2011/10/12(水) 14:54:22.27

中央にコミットするまでのあるまとまった単位の修正だろ？
そんなもん#if 0 #else #endif とかコメントで十分だろ

341 ：デフォルトの名無しさん：2011/10/12(水) 14:57:03.11

え？svn使いってそんなことしてんの？いまどき？
それで十分ならマスターリポジトリもそうやって管理したら？

342 ：デフォルトの名無しさん：2011/10/12(水) 15:00:17.54

ローカルな試行錯誤を小刻みにコミットしながらできるのは便利だよ。
そして、その試行錯誤を1～複数のコミットに整理してから、管理されているリモートにpullしてやればいい。

管理されるのは、ごちゃごちゃな試行錯誤より、整理された試行錯誤のほうがいいよ。

343 ：デフォルトの名無しさん：2011/10/12(水) 15:00:29.63

実際それでうまくいってるし２重管理の必要性を感じない
マージするより#if #else でパッと見で分かる方が早いじゃん

344 ：デフォルトの名無しさん：2011/10/12(水) 15:05:21.76

Gitは漠然とした仕様の中手探りで開発するときに向いている。
自分でソフトウェアやプラグインを作るときは仕様の変更や試験的な実装がしょっちゅうあるだろ。

345 ：デフォルトの名無しさん：2011/10/12(水) 15:12:12.23

>>335
回線のつながってない客先にどうやって納品するの？
まさかzip？
それで客先で改変してカオスになるわけだ。

346 ：デフォルトの名無しさん：2011/10/12(水) 15:15:33.01

いつまで小学生構ってるんだよ・・・

347 ：デフォルトの名無しさん：2011/10/12(水) 15:16:49.69

>>337
bundle

348 ：デフォルトの名無しさん：2011/10/12(水) 15:19:01.27

>>346
ここはまんこスレだから

349 ：デフォルトの名無しさん：2011/10/12(水) 15:35:31.42

うんこすれですよ

350 ：デフォルトの名無しさん：2011/10/12(水) 15:36:58.20

>>335当たり前のことだが、リモートに全く接続しないわけでなく、リモートに接続する頻度が減るだけだからな。

351 ：デフォルトの名無しさん：2011/10/12(水) 15:38:50.88

じゃあお前ら#if #elseで処理を有効/無効化したりコメント化したりせずに
わざわざ現状をローカルコミットして処理を消して書き直したりしてんの？
コードに残しときゃすぐ分かるのにバカじゃね

352 ：デフォルトの名無しさん：2011/10/12(水) 15:48:55.65

>>351
Linuxカーネルでは#ifは禁止。
コミットログに書いて十分なものを、コメントに書くのは馬鹿。
コメントはメンテされていないことがほとんど。信用できない。

353 ：デフォルトの名無しさん：2011/10/12(水) 15:56:09.42

別にLinuxカーネル作ってるわけじゃねーしｗ
ローカルコミットの内容だって信用できないものなのに大事に保管しとく意味ねーだろ

354 ：デフォルトの名無しさん：2011/10/12(水) 15:59:07.30

>>353
svnのコミットは信用できるのか？

355 ：デフォルトの名無しさん：2011/10/12(水) 16:21:18.26

もはやVCSそのものを否定してるレベルだな
なんでsvn使ってるんだ？

356 ：忍法帖【Lv=40,xxxPT】：2011/10/12(水) 16:24:46.00

>>351
そんな意味のないプリプロセッサ付けんな! ソースが汚くなって見辛いし、ほんとに大事なものが見えなくなる。

357 ：デフォルトの名無しさん：2011/10/12(水) 16:31:32.11

>>351
ファイルが無駄にでかくなるし、そもそも修正履歴が追えないだろ

358 ：デフォルトの名無しさん：2011/10/12(水) 17:09:35.70

>>355
うんこなソースの肥溜め

359 ：デフォルトの名無しさん：2011/10/12(水) 17:40:10.63

#if がどっさりうまったうんこコードを書く小学生がいるスレはここですか？

360 ：デフォルトの名無しさん：2011/10/12(水) 18:28:06.34

試行錯誤の段階の話だろうが
最後は綺麗にしてコミットするに決まってるだろ
日本語もまともに読めないカスどもが２重管理地獄で悶絶して市ね

361 ：デフォルトの名無しさん：2011/10/12(水) 18:33:01.30

>>360
試行錯誤でも#if使うのはうんこ

362 ：デフォルトの名無しさん：2011/10/12(水) 18:35:38.48

>>360
その「最後は綺麗にしてコミット」するのが圧倒的に楽なのよ。
Gitで>>342のやり方をすれば。

363 ：デフォルトの名無しさん：2011/10/12(水) 19:08:45.38

ブランチの概念を教えたほうがいいかもしれない

364 ：デフォルトの名無しさん：2011/10/12(水) 20:01:29.80

どんだけ大規模な試行錯誤してんの？
#if #else自体もほとんど使う機会ないんだけど
ローカルでそんな大規模な修正してて中央にコミットするときに競合した場合に
ものすごく面倒臭いんじゃないの？競合相手も大規模な試行錯誤してんだろう？

365 ：デフォルトの名無しさん：2011/10/12(水) 20:07:09.87

試行錯誤がフィーチャーブランチだったら公開した方がみんなのためだろう
svnはブランチがうんこだからできないけど

366 ：デフォルトの名無しさん：2011/10/12(水) 20:18:54.24

コーディング規約で過去コードをコメントや#ifで残すようにとか決まってるんじゃないの？
そういう時にはチーム内管理用のコードと正式コミット用のコードをブランチで分けるんだよ

で、邪魔なコメント過去コードは正式コミット用コードにだけ残しておいて、
プロジェクトリーダーが週例前に内部用コードとマージして一括してコミットする。

367 ：デフォルトの名無しさん：2011/10/12(水) 20:32:11.21

ただ宗教戦争したいだけのヤツなんだからもういいかげん相手にするなよ・・・

368 ：デフォルトの名無しさん：2011/10/12(水) 20:44:01.79

>>367
神聖なまんこスレからうんこは排除せねばならない

369 ：デフォルトの名無しさん：2011/10/12(水) 20:55:48.66

>>364
数行の修正×数箇所とか程度の簡単な修正でもGit使うと楽よ。
エディタでソース修正してローカルなコミットを作った後は、
動作確認して必要なコミットだけをまとめてコメント付け直してリモートに登録するとかを
コマンド叩くだけでできるし。

#if#elseとかでやる場合は最後もエディタでソースを整形しなおすんでしょ？
その段階で修正間違えたりしたら目も当てられない。

370 ：デフォルトの名無しさん：2011/10/12(水) 21:25:50.32

たとえば、ファイル a, b, c の３つで、 #if によるコメントアウトを同時に行わないと、効果が無い場合。
a, b, c の修正を採用するか、不採用にするか、いずれにしても、３つのファイルから #if を最終的に掃除する作業を行うことになる。

a, b, c のへの修正を、仮に A とする。
git だと branch A として修正を行ったバージョンを実験できる。
それを採用するならば git merge A として master へ合流させればいいし、不採用なら採用しなければいい。

わざわざ #if を掃除する方法だと、掃除の段階でミスする可能性もある。
たとえば a, b の #if だけ掃除して c の #if を掃除し忘れるような心配も無い。

a,b,c とは別の流れで a, x, y の修正も必要な場合、
git なら a, x, y への修正を仮に B とし、採用なら git merge B すれば良い。

A, B での最終的な採用パターンは４つ。　両方採用、片方採用、両方不採用の４つ。
これを最終的に #if の掃除として行うとしたら面倒。
さらに A, B, C の修正を α 、A, X, Y の修正を β とするような規模になれば、ローカルで自由にcloneできることのメリットを享受できる。
大規模な修正 α, β のために、それぞれclone して独立して修正を行ってしまってもいい。
そして、両方採用（α,β）ならば、α内からβをpullすればいいし、片方採用ならそれをコミットすればいいし、両方不採用なら捨てればいい。

これらは全てローカルでの話。
こうして作ったパッチを最終的に中央へコミットすることになる。 gitには決まった使い方は無い。使い方を自由に工夫できる余地が残されている。

371 ：デフォルトの名無しさん：2011/10/12(水) 22:05:14.52

機能A追加、機能Aを使う機能B追加、機能Bを使う機能C追加

のような3つのコミットをしたい時に、機能Cを作りながら機能A、Bもデバッグ
して、きれいにして、最後に3つに分けるんだけど、後から分割するのって大変
なんだよね。そういうのは、gitやhgだとコミットを行ったり来たりしながら作
業できて便利。だから例えsvnでやれと言われても、手元でgitとか使っちゃう
と思う。

372 ：デフォルトの名無しさん：2011/10/12(水) 22:42:05.11

>>343
よかったな。リリースされたSVN1.7.0でも2重管理とやらの機能が強化されたぞ。
http://subversion.jp/index.php?option=com_content&view=article&id=50:subversion17enable-git-like-features&catid=25:subversion-article&Itemid=27

373 ：デフォルトの名無しさん：2011/10/13(木) 01:22:56.98

GitHub のデザイン変わった？

374 ：デフォルトの名無しさん：2011/10/13(木) 11:37:34.43

gitはPerforceが高くて買えない貧乏人に最適
むしろgitの方が優れてるし
つまり、全人類にとっての光明

375 ：デフォルトの名無しさん：2011/10/13(木) 12:40:01.95

今度は買い物P4厨を呼び込むための撒き餌か!?

宗教戦争とか政治論争は別のスレでやろうや。

376 ：デフォルトの名無しさん：2011/10/13(木) 16:54:08.89

git 1.7.7 の msys版がでたけど、
msysGit-fullinstall-1.7.7-preview20111012.exe からだと
生成されるファイルのサイズが全然違うのはなんでだろうか。
--version の表示結果からして違うせいなのか、
デバッグ用の実行ファイルになってるのかな

377 ：デフォルトの名無しさん：2011/10/13(木) 19:55:32.92

>>372
それは誤読もいいところ。
そこに書いてあって1.7で実現されたgit的なものは
.svnがひとつになったことぐらい。
これは無条件に良くなったと言える。

378 ：デフォルトの名無しさん：2011/10/13(木) 19:59:36.91

じゃあ相変わらず #if 使う日々が待ってんのか
大変だな

379 ：デフォルトの名無しさん：2011/10/13(木) 21:26:01.98

1.7のリリースまでにはまとめられなかっただけだろ。
2重管理とやらをしてないのに。

380 ：デフォルトの名無しさん：2011/10/13(木) 21:29:40.03

2重管理地獄の中で悶えて死ね

381 ：デフォルトの名無しさん：2011/10/13(木) 23:56:21.07

Git使ってると気持ち良くて悶えちゃう

382 ：デフォルトの名無しさん：2011/10/13(木) 23:58:52.37

>>380
お前もローカルでは #if で手動管理してるんだろ？
まあ管理と呼ぶのもおこがましいが

383 ：デフォルトの名無しさん：2011/10/14(金) 02:20:43.90

流れ読まずに横から質問…。

ローカルに好き勝手なタイミングでコミットしまくって出来上がった、うまく言語化できない成果物があるとして
それをいわゆる中央リポジトリにキレイな履歴で送りつけたいとき、
みんなは具体的にはどうやって整理してるの？

もしやsvnとかとは、コミットの粒度がケタ違いに違う？

384 ：デフォルトの名無しさん：2011/10/14(金) 02:47:30.64

>>383
分離すべきと思う単位で分割するかな。つまり機能毎に。
関数追加～とかの単位だと意味が無いし、逆に複数の機能が単一のコミットに入っていると
一部だけ採用できない。
また、ビルドが通らないというのは論外だけど、例えば「新機能1」「新機能1のテストコード」
とかは同じコミットにすべきだし、単体で意味のあるバグ修正なんかは別のブランチに
してマージしたい。俺は。

385 ：デフォルトの名無しさん：2011/10/14(金) 04:30:35.56

公開リポジトリまたは他人のリポジトリには、基本、
「この機能いらないからこのコミットだけ却下」
ということができるようにローカルで調整してコミットしたブランチを送りつける

いやもちろんプロジェクトのポリシー次第なのだが
単一の機能を実現するためにあちこちいじらないといけないときは説明的なコミット満載の単一のブランチにしたりもする
あちらでsqashしてくれるんだろうと思ったらそのままブランチごと適用されてお茶吹いたりもするのであんまり勧めない

386 ：デフォルトの名無しさん：2011/10/14(金) 06:33:17.19

>>379
svn1.7ではクライアントにsqliteを使うことで２重管理を実現しています
http://subversion.jp/index.php?option=com_content&view=article&id=74:apachesubversion17-releasenote&catid=25:subversion-article&Itemid=27

387 ：デフォルトの名無しさん：2011/10/14(金) 06:35:24.18

>>377
残念ながらsvn1.7ではsvnユーザが行っていた２重管理はできなくなりました。
> **警告**: SQLiteライブラリを通じてSQLiteにアクセスがある間に、SQLiteのファイルをコピーするのは安全ではありません。
> 結果として、 Subversionプロセスからアクセスされているワーキング・コピーの複製を作る事(tar, rsync, cpなどで)は、
> Subversion1.7ではサポートされません。それは壊れている可能性があります。(課題 #3596)

388 ：デフォルトの名無しさん：2011/10/14(金) 06:39:26.99

>>383
最終的には科学的な指標なんてなくて、美的センスの問題。

383の改行が、いうなれば、パッチ整理のようなもの。

１改行は、それぞれが強く関連する、小さな意味単位としての分割。
２改行は、それらのグループ間での分割。

パッチの分割も３８３の文章と同じ要領。結局これは、最後は美的センスの問題になる。
機械的で具体的な数字には示し難い。

389 ：デフォルトの名無しさん：2011/10/14(金) 07:10:39.64

>>386-387
いいかげんウザい
馬鹿に付き合ってるお前も馬鹿に見えてるのに気付け

390 ：デフォルトの名無しさん：2011/10/14(金) 07:49:10.23

今時VCSにSQLiteを使うのは馬鹿だな

391 ：デフォルトの名無しさん：2011/10/14(金) 10:41:29.00

>>390
どうちて？

392 ：デフォルトの名無しさん：2011/10/14(金) 11:11:53.08

>>391
SQLiteはロック前提だから。
そんなことも分からないsvn開発者は馬鹿。

393 ：デフォルトの名無しさん：2011/10/14(金) 11:21:55.97

ありがとう。ちょうどsvnスレでその話挙がってるね。スレ違いすまんこ。

394 ：デフォルトの名無しさん：2011/10/14(金) 12:19:33.60

きにすんなちんこ

395 ：デフォルトの名無しさん：2011/10/14(金) 16:17:42.57

BerkeleyDB依存からは脱却できたのに…

396 ：デフォルトの名無しさん：2011/10/15(土) 08:09:23.33

なにか要求をシリアライズしているプロセスをかませばいいのに
それこそhttpdの何かとか

397 ：デフォルトの名無しさん：2011/10/15(土) 15:27:30.20

gitの中にはファイルの所有者の情報を保存できないのでしょうか？
chownしてdiffしても何も変わっていないと言われてしまいます

398 ：デフォルトの名無しさん：2011/10/15(土) 16:20:05.56

>>397
できないよ。実行可能かどうかだけ。あとシンボリックリンクはだいじょうぶ。

399 ：デフォルトの名無しさん：2011/10/15(土) 17:39:52.35

>>398
そうなのですか
ありがとうございました

400 ：デフォルトの名無しさん：2011/10/16(日) 14:01:25.77

Git ってたまたまハッシュ値が衝突しちゃった場合ってどうするようになってるの？

401 ：デフォルトの名無しさん：2011/10/16(日) 14:14:39.39

どうもしない

402 ：デフォルトの名無しさん：2011/10/16(日) 14:25:10.57

>>400
前スレの最初の方でやった

403 ：デフォルトの名無しさん：2011/10/16(日) 15:02:17.72

変な動作でエラーになると思われる
（やろうとした処理にもよるが、無言で上書きされて続行されるようなことにはならない、はず）
まあ、エラーになったならそのとき手で修正すればいい
天文学的確率のさらに上をいく事象に事前対処することはリソースの関係上できね

あと、これも前スレで言われてるが、ハッシュに日付とかユーザー名とかくっつけるのは衝突回避確率を強化しない

404 ：デフォルトの名無しさん：2011/10/16(日) 15:21:17.02

ttp://progit.org/book/ja/ch6-1.html
> すでにリポジトリに存在するオブジェクトと同じ SHA-1 値を持つオブジェクトをコミットしてした場合、
> Git はすでにそのオブジェクトがデータベースに格納されているものと判断します。
> そのオブジェクトを後からどこかで取得しようとすると、
> 常に最初のオブジェクトのデータが手元にやってきます
> (訳注: つまり、後からコミットした内容は存在しないことになってしまう)。

まったく調べずに嘘を書くのはどうかと

405 ：デフォルトの名無しさん：2011/10/16(日) 19:19:53.77

おまえみたいに調べて訂正してくれるやつがいるから
ある意味問題ないな

406 ：デフォルトの名無しさん：2011/10/16(日) 19:24:16.94

俺の間違い push も訂正してほしい

407 ：デフォルトの名無しさん：2011/10/16(日) 20:36:16.79

うん？コミット時にはエラーでなくてあとで困るってこと？
それってまずくね

408 ：デフォルトの名無しさん：2011/10/16(日) 20:40:22.26

その前にオオカミの心配しろよ

409 ：デフォルトの名無しさん：2011/10/17(月) 09:12:15.64

SHA1ハッシュが衝突したとしてもオブジェクトの種類が違ったら
たぶんエラーになるから、さらに確率は下がるかな。

410 ：デフォルトの名無しさん：2011/10/17(月) 13:16:40.23

悪意を持って衝突させる奴が出たらそんなこと言ってられない

411 ：デフォルトの名無しさん：2011/10/17(月) 13:22:32.50

質問です。
git svn clone して以下のように作業しているんですが...

1. branch を作って作業
2. master にマージ
3. git svn dcommit

このあと、
branch は要らなくなったので git branch -d すると

　　error: The branch '○△□' is not fully merged.
　　消したかったら -D で消せ

と怒られます。

git svn dcommit すると、
commit のハッシュ値みたいなのも変わりますので
怒られるのは当たり前だとは思います。
・・・が、
　　2. master にマージ
　　3. git svn dcommit
の間に要らなくなったブランチを削除しておくのが普通なのでしょうか?

412 ：デフォルトの名無しさん：2011/10/17(月) 13:22:40.31

anonymousでpushできる世界の話？

413 ：デフォルトの名無しさん：2011/10/17(月) 13:30:07.71

2重管理で悶えてるじゃねーかｗ

414 ：デフォルトの名無しさん：2011/10/17(月) 18:39:45.51

>>322

415 ：デフォルトの名無しさん：2011/10/17(月) 22:43:50.41

二重管理ってgit-svnのことだったのかよｗ

416 ：デフォルトの名無しさん：2011/10/17(月) 22:46:10.96

>>413
無駄だ

417 ：デフォルトの名無しさん：2011/10/17(月) 23:54:08.81

>>410
意図的にSHA-１を衝突させるとか何者？

418 ：デフォルトの名無しさん：2011/10/18(火) 00:00:29.53

>>410
できないできない絶対できない
やれない気持ちの問題じゃない

419 ：デフォルトの名無しさん：2011/10/18(火) 00:02:40.58

できるできる絶対できる！

420 ：デフォルトの名無しさん：2011/10/18(火) 00:11:19.82

たとえ将来、自由にハッシュを衝突させることができるようになったとしても
既存のリポジトリの内容を破壊できるわけでもなんでもないその行為になんの意味があるの？

421 ：デフォルトの名無しさん：2011/10/18(火) 00:19:18.86

// コメントを外すと何故かコミットできない

422 ：デフォルトの名無しさん：2011/10/18(火) 01:19:44.68

>>411
master で dcommit したら topicブランチの方でも git svn rebase とか
git rebase master とかすると、ハッシュ値が違う同じコミットが整理されて、
git branch -d で消せるようになるよ。

＞2. master にマージ
これって merge っていうか FastForward だよね？
あと dcommit する前にも git svn rebase するはず。
git svn じゃなくても rebase すると -D じゃないと消せないはぐれブランチが
出来る可能性はある。

423 ：デフォルトの名無しさん：2011/10/18(火) 06:14:39.87

>>411
俺はmerge時には--no-ffしてる。

424 ：デフォルトの名無しさん：2011/10/18(火) 08:05:41.70

411です。
ありがとうございました。
今日もういちど
しらべたりやってみたりしようと思います。

425 ：デフォルトの名無しさん：2011/10/18(火) 12:40:59.27

質問です。

masterからtestブランチをつくってcoし、testブランチのほうであるファイルの内容を
変更しました。statusを見てみると、たしかにadd待ちになっています。

その状態でcoしてまたmasterに戻り、なんとなくstatusを見てみると、
ブランチで作業したファイルが、こちらでも変更されたことになっています・・・
ファイルの内容を確認すると、ブランチでの変更と同じものになってしまっています。

ここでまたcoしてtestブランチに戻り、addしてmasterに戻ると、
こちらでもaddされてcommit待ちになっています。

これはこういうもので、ブランチで作業した場合、
commitせずにmasterに戻るのは間違いということでしょうか。
まだgitを使い始めて日が浅いので、誤操作したのかもしれませんし、
正しく理解できていないところもたくさんあると思いますが、
ちょっと困惑してますので、ご教示ください。

426 ：デフォルトの名無しさん：2011/10/18(火) 12:48:01.10

2重管理地獄の中で悶えて死ねｗ

427 ：デフォルトの名無しさん：2011/10/18(火) 13:09:33.26

>>322

428 ：デフォルトの名無しさん：2011/10/18(火) 13:15:06.14

>>425
addしていないファイルはどのブランチにも属さない
単に管理されていないから、どのブランチにいても「未管理ファイル」として表示される
それだけ

429 ：デフォルトの名無しさん：2011/10/18(火) 13:18:41.03

あー、なんとなくわかってきました。

testのほうでadd/commitするとtestが新しくなり、
masterに切り替えると古い版が維持されてました。

最初からやりなおしてまたtestで修正し、今度はmasterに切り替えてこっちで
add/commitすると、masterが新しくなり、testのほうが古いmasterの状態を
維持してました。

こういうものなんですね。co すると、そのブランチの
（こっちが期待している元の）状態に全部きれいに切り替えてくれるものと
思ってましたし、ブランチでの修正をmasterでcommitできるとか
考えてもみませんでした。
たぶん私は「ブランチ」の概念から理解しなおさないとダメですね。

430 ：デフォルトの名無しさん：2011/10/18(火) 19:23:36.94

ブランチというか、ステージングの概念じゃない？
ワークツリーの変更を退避したければ git stash でできるよ
でも、とりあえずコミットしておいてあとでコミットを編集・整理するのでも良いと思う

431 ：デフォルトの名無しさん：2011/10/18(火) 19:25:39.62

概念がどうとかいうほどのもんかね？

432 ：デフォルトの名無しさん：2011/10/18(火) 19:26:24.02

gitってうんこだな

433 ：デフォルトの名無しさん：2011/10/18(火) 19:32:13.07

>>431
いやだってbranchとは別物じゃない

434 ：デフォルトの名無しさん：2011/10/18(火) 19:58:28.05

gitはbranchとstashの2重管理のうんこ

435 ：デフォルトの名無しさん：2011/10/18(火) 22:49:25.35

あれからあらためてman読んだり自分で考えたりして、それなりにわかりました。
gitにはようするに「コミットオブジェクト」みたいなものしかないわけですよね。
タグはもちろんブランチも、ユーザのための記号みたいなもの。

だからブランチをつくったばかりなら、両ブランチは対等というかおんなじもので、
どちらが親とか、そういう意味もない。コミットした時点で初めて、
新たな「コミットオブジェクト」がつくられる。
あるコミットオブジェクトがどのオブジェクトから派生したか、といった情報は、
オブジェクトがつくられるときに記録される。

こう考えるとすごくわかりやすくなりましたし、シンプルでいいな、と思いました。
こんな感じに理解しましたが、だいたい合ってますでしょうか？

436 ：デフォルトの名無しさん：2011/10/18(火) 23:35:29.83

だいたい合ってる
しいていえばタグは特定のコミットをピンポイントで指すけど、ブランチはコミットの歴史（HEADの変遷）を指すってところかな

437 ：デフォルトの名無しさん：2011/10/19(水) 00:03:29.96

Git のタグは、軽量 (lightweight) 版と注釈付き (annotated) 版の2重管理のうんこ

438 ：デフォルトの名無しさん：2011/10/19(水) 00:30:05.82

バージョン管理システム界にカオスと混乱を招いたgitの罪は重い

439 ：デフォルトの名無しさん：2011/10/19(水) 00:45:54.69

>>436
ありがとうございます。
タグとブランチの違いについても考えてましたけど、おおむね間違ってなかったみたいです。

使いかたはまだまだ練習中ですが、いろいろわかってきたので面白いです。

440 ：デフォルトの名無しさん：2011/10/19(水) 08:05:53.27

gitを理解できない奴の頭の中がカオスになってるだけだろ。
自分の頭の悪さを罪だと思えｗ

441 ：デフォルトの名無しさん：2011/10/19(水) 08:30:20.91

構うなベアード

442 ：デフォルトの名無しさん：2011/10/19(水) 08:58:52.72

>>435
シンプルでいいよね。そこに気づけばもう迷うことはないよ。
必要に応じてコマンド覚えていけばいいだけ。おめでとう。

443 ：デフォルトの名無しさん：2011/10/19(水) 15:48:27.96

今一番使われているバージョン管理システムってgitなんすか

444 ：デフォルトの名無しさん：2011/10/19(水) 16:07:14.60

ちょっと調べてみて使い方がスっと入ってこない時点でうんこ

445 ：デフォルトの名無しさん：2011/10/19(水) 19:43:26.24

>>443
今一番使われてるのはSubversion
オープンソース開発でGitが増えている

一般の開発でもGitが増えつつある。
svn→gitは便利になることもある反面失うものも多いから
単純に置き換えが進むというものではなくてずっと共存すると思う。

過去、cvs→svnはなにも失うものが無かったから一気に移行が進んだ

446 ：デフォルトの名無しさん：2011/10/19(水) 20:05:51.00

失うものがないもっと良いやつ作れよ
何が分散型だよ中央とローカルで２つsvnリポジトリ持ってるのと一緒じゃねーかｗ

447 ：デフォルトの名無しさん：2011/10/19(水) 20:08:14.93

失うもの "SVN厨"

448 ：デフォルトの名無しさん：2011/10/19(水) 20:14:24.67

何かを得れば何かを失う。人生とはそんなものだ。
状況に応じて使うか使わないかを決めるといい。

449 ：デフォルトの名無しさん：2011/10/19(水) 20:14:40.98

失うもの
・コミッタの特権
・リビジョン番号
・svn的なタグ・ブランチ

450 ：デフォルトの名無しさん：2011/10/19(水) 20:22:17.82

Linusも開発してて途中でうんこだと気付いたから手を引いたんだろうな

451 ：デフォルトの名無しさん：2011/10/19(水) 20:45:32.75

使えないとか言ってるやつはとりあえずこれ読んでこの通りブランチ運用してみろ

A successful Git branching model(翻訳)
http://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html

ある程度やったらGit log --graph --statってやってみ
こりゃ便利だと思うぞ

452 ：デフォルトの名無しさん：2011/10/19(水) 20:47:39.83

で、あのおっさんがうんこと気づかずにメンテナ面して得意満面にいじくりまわしてるってか?

…ちがうだろ、基本設計が良かったから発展し続けてるんだろ?
俺は単にJunioのことをおっさん呼ばわりしたかっただけだw

453 ：デフォルトの名無しさん：2011/10/19(水) 20:54:26.03

>>451
グラフがうんこになるのを推奨している記事か

454 ：デフォルトの名無しさん：2011/10/19(水) 20:55:34.40

うんこを押し付けられてせっせとメンテナンスするおっさん…

455 ：デフォルトの名無しさん：2011/10/19(水) 20:59:19.29

svnみたいなうんこツール使ってると性格までうんこになるのか

456 ：デフォルトの名無しさん：2011/10/19(水) 21:00:32.44

gitは中途半端でめんどくさいツールでＦＡ
たぶん3年後くらいにちゃんとした次世代バージョン管理システムができるから
それまでsvnでいいや

457 ：デフォルトの名無しさん：2011/10/19(水) 21:03:15.06

>>456のほざく「次世代」に「SVNと同様の」が多分に含まれてる汚感。

458 ：デフォルトの名無しさん：2011/10/19(水) 21:09:17.58

>>457
つBazaar

459 ：デフォルトの名無しさん：2011/10/19(水) 21:26:06.35

うんこ話は盛り上がるがまんこの方が好き
盛りまん

460 ：デフォルトの名無しさん：2011/10/19(水) 22:03:50.73

>>446
Mercurialならgitより失うものは少ないんじゃね

461 ：デフォルトの名無しさん：2011/10/19(水) 22:15:51.61

git log --name-status -M

とかやると移動の履歴も見れて素敵なんだけど
ファイルステータスの記号に続く3桁の数字の意味ってなんなんだろう。
R077 R100 とか、合致率とかかな？

462 ：デフォルトの名無しさん：2011/10/19(水) 23:41:34.07

>>449
＞・コミッタの特権
これかなりメインテーマだよな。

>>461
多分そうだろうなーと俺も思ってた。

463 ：デフォルトの名無しさん：2011/10/19(水) 23:57:55.46

TortoiseGitのFormat patchで作ったパッチ、何でファイル名の前に
a/とかb/がつくの？付けさせない方法ないの？

464 ：デフォルトの名無しさん：2011/10/19(水) 23:59:34.28

番号飛びすぎﾜﾛﾀwwww
まだ一所懸命やってるようだな。ご苦労なことだ。

465 ：デフォルトの名無しさん：2011/10/20(木) 06:47:53.91

>>463
diff.noprefix のことだとは思うが後悔するなよ? tgit で試してないから知らん。

466 ：デフォルトの名無しさん：2011/10/20(木) 12:17:02.67

>>446
良いよ。いくら払う？

467 ：デフォルトの名無しさん：2011/10/20(木) 12:44:32.82

>>446
svkのこと？

468 ：デフォルトの名無しさん：2011/10/20(木) 13:03:19.48

かかってこいよ

469 ：デフォルトの名無しさん：2011/10/20(木) 18:56:12.46

さっさとかかってこいよブタ共

470 ：デフォルトの名無しさん：2011/10/20(木) 19:13:18.48

471 ：デフォルトの名無しさん：2011/10/21(金) 08:14:27.43

gitで管理しているディレクトリの配下に、
他のリポジトリからディレクトリをcloneしたりしたら問題になりますか？

472 ：デフォルトの名無しさん：2011/10/21(金) 08:51:50.02

>>471
addしなけりゃいいだけだ。
してもgit的には問題は無いけどまあ普通しないわな。

473 ：デフォルトの名無しさん：2011/10/21(金) 09:46:45.30

>>471
submodule使おう

474 ：デフォルトの名無しさん：2011/10/21(金) 12:52:54.39

--reference (objects/info/alternates) に含まれているオブジェクト以外を prune することってできる?
もちろん alternates の先はオブジェクトが消滅せずひたすら追加されていく前提で。

475 ：デフォルトの名無しさん：2011/10/21(金) 12:53:50.02

>>474 うわ日本語間違えた。
「alternates が保持しているオブジェクトをローカルオブジェクトから prune」だ。

476 ：デフォルトの名無しさん：2011/10/21(金) 23:01:08.48

Bazaarスレ、なんか埋め立てられているし

477 ：デフォルトの名無しさん：2011/10/21(金) 23:06:37.77

分散型バージョン管理システムとは３ＤＳみたいなもの

478 ：デフォルトの名無しさん：2011/10/22(土) 00:34:59.24

cvs:ゲームボーイ
svn:DS
git:3DS

479 ：デフォルトの名無しさん：2011/10/22(土) 02:03:17.54

cvs:ゲームボーイ
svn:ゲームボーイカラー
git:DS

480 ：デフォルトの名無しさん：2011/10/22(土) 06:33:19.13

cvs:ファミコン
svn:スーファミ
git:バーチャルボーイ

481 ：デフォルトの名無しさん：2011/10/22(土) 09:18:25.92

やれやれだ

482 ：デフォルトの名無しさん：2011/10/23(日) 19:28:28.36

サードパーティというかベンダというか、そういう外部由来のソースの小さなバグ直したり、
ちょこっと「自分仕様」を追加したりしつつ利用していくときって、
ブランチはオリジナル版とカスタム版のどっちをmasterにしとくのがいいんでしょう？
オリジナル版の更新も取り込みつつ、カスタム版をメインに利用する、
と考えると、master/vendor っていう分けかたがいいのかな、とは思うんですけど・・・

483 ：デフォルトの名無しさん：2011/10/23(日) 19:54:13.12

どうでもいいよ
pull/pushするときに送信ブランチ名と送信先ブランチ名を指定できる（つまり、送受信時に自由にリネームできる）から、手元では好きに名前をつけるといい

484 ：デフォルトの名無しさん：2011/10/23(日) 20:30:04.96

もっと言うと master というブランチ名自体に特別な意味はない。

一般的には外部由来のもの、すなわち pull 専用のものを origin/master -> master として
自分用ブランチを設けて好き勝手にやるのが自然。

上流(この場合外部)に自分の変更の一部を反映するための方策についてはまた別の話。

485 ：デフォルトの名無しさん：2011/10/23(日) 20:47:15.83

いちおう慣習的なブランチの名前というのはいくつかあったはず

486 ：482：2011/10/23(日) 21:40:50.26

なるほど、これといったルールはないんですね
ただのzipとかtarballでしか配布されてないものなんかも想定しているので、
自分がわかりやすいと思う分けかたでやっていくことにします

487 ：デフォルトの名無しさん：2011/10/26(水) 20:47:17.46

他の開発者との中央へのコミット内容が競合した場合の対応ってgitだとsvnより楽だったりしますか

488 ：デフォルトの名無しさん：2011/10/26(水) 21:27:48.69

つーかSVNが苦行

489 ：デフォルトの名無しさん：2011/10/26(水) 21:35:10.19

うんこよりマシ

490 ：デフォルトの名無しさん：2011/10/26(水) 21:57:09.24

>>487
楽だよ。3wayマージ賢い。
さすがに同じタイミングでがっつり同じ箇所ぶつかったら
手でマージすることになるけど、補助ツール使えばなんとかなる。

491 ：デフォルトの名無しさん：2011/10/26(水) 22:51:45.87

バイナリ込みで数十 GB とかいける?

492 ：デフォルトの名無しさん：2011/10/26(水) 23:39:13.23

いけると思うけどでかいバイナリを頻繁に変更するならちょっときついかもしれない

493 ：デフォルトの名無しさん：2011/10/27(木) 00:37:19.80

target ディレクトリを毎回コミットする奴にはどういえば直るだろうか

494 ：デフォルトの名無しさん：2011/10/27(木) 07:53:31.04

>>493
TortoiseGit 病だな?

495 ：デフォルトの名無しさん：2011/10/27(木) 09:04:05.61

>>493
gitignoreしたらどうなの？

496 ：デフォルトの名無しさん：2011/10/27(木) 17:07:40.40

3wayマージは補助でp4merge使うと、ほとんど手修正しなくていいぞ

497 ：デフォルトの名無しさん：2011/10/27(木) 22:20:26.99

>>495
新規モジュールでやられてしまうので

498 ：デフォルトの名無しさん：2011/10/28(金) 10:27:29.73

開発ブランチ(master)と、リリースブランチ(rel-X.X)とがあって、リリースブランチ（または開発ブランチ）に行ったcommitを、もう一方のブランチにcherry-pickしています。
このとき、両ブランチの間でどのコミットがcherry-pickされていて、どのコミットがされてないかを調べるいい方法はないでしょうか。

499 ：デフォルトの名無しさん：2011/10/28(金) 11:28:41.10

git pullを試みたところ、
error: Your local changes to the following files would be overwritten by merge:
と言われました。しかし、今現在worktreeにある変更はどうでもいい些細なものなので、worktreeにある変更を
破棄して、とにかくpullしたいです。どうすればいいですか？

500 ：デフォルトの名無しさん：2011/10/28(金) 11:32:47.15

>>499
よーわからんけど、ローカルの変更がどうでもいいなら全部消してcloneし直せばいいんじゃ？

501 ：デフォルトの名無しさん：2011/10/28(金) 12:46:04.13

>>499
競合のあるbranch上で git reset --hard origin/upstream_worktree

502 ：デフォルトの名無しさん：2011/10/28(金) 13:12:17.86

>>498
git cherry -v branchA branchB
で、ある程度分かるかもしれない

503 ：デフォルトの名無しさん：2011/10/28(金) 14:04:15.67

>>502
git checkout rel-X.X
git cherry -v --abbrev=8 master
で望みの結果が得られました。
+ が、rel-X.X にだけ適用されて、masterには適用されてないcommit、
- が、rel-X.Xとmasterの両方に適用されているcommit
のようです。
ありがとうございました。

504 ：デフォルトの名無しさん：2011/10/28(金) 15:39:51.17

また２重管理で苦しんでるな
何の罪も無い純粋な技術者がなぜ苦しまなければならないのか

505 ：デフォルトの名無しさん：2011/10/28(金) 15:49:26.51

別に苦しんでないだろ
自分で調べるのが面倒なのがここで質問して、おせっかい焼きが答えてるだけ

506 ：デフォルトの名無しさん：2011/10/29(土) 13:35:21.20

HEADだけcloneするにはどうやればいいのでしょうか？

507 ：デフォルトの名無しさん：2011/10/29(土) 15:12:07.97

なんだそりゃ
全ファイルの旧編集履歴をひとつの最新コミットに詰め込んで新たに履歴1個だけのブランチを作りたい？

508 ：デフォルトの名無しさん：2011/10/29(土) 15:37:35.49

Signed off by って Linus のオナニー以外に何の意味があるの？

509 ：デフォルトの名無しさん：2011/10/29(土) 15:46:14.22

ユーザー無視の開発者のオナニーの産物

510 ：デフォルトの名無しさん：2011/10/29(土) 20:54:41.26

なんでSigned-off-by:がLinusのオナニーってことになるのか意味不明。
著作権者をtrackするための重要な情報なのに。

511 ：デフォルトの名無しさん：2011/10/29(土) 21:39:58.53

元の作者を尊重しつつ、コード作成とコミットの責任所在をわけることが出来る
仕組みのはずなんだが、Sign-Offに名前が出ることが売名行為に見えてるんだろうね。

512 ：デフォルトの名無しさん：2011/10/29(土) 22:12:58.99

名無しさん以外のものを拒絶する2chならではの反応だなぁ、と

513 ：デフォルトの名無しさん：2011/10/29(土) 22:45:05.74

author と comitter の違いとは別なの？

514 ：デフォルトの名無しさん：2011/10/30(日) 04:12:17.33

>>506
git clone --depth 1
その後出来ることに制限があるのでman見たりググったりしてくれ

515 ：デフォルトの名無しさん：2011/10/30(日) 15:37:19.58

>>513
新たにcommitができるような場面では committer が作業者のものになる。
(git-am, git-cherry-pick など).
このとき committer date も更新することになる。
git-commit --amend, conflict merge など、作業者の変更の余地が入るような commit では author も上書きされる。

のような運用だが、 git-commit (もしくは git-commit-tree) にて任意に上書き可能。

516 ：デフォルトの名無しさん：2011/10/31(月) 21:00:38.97

$ git pull
Your configuration specifies to merge with the ref 'master'
from the remote, but no such ref was fetched.
というメッセージが出るんですが、これってどういう意味ですか？
「ref」はブランチのこと？
もしそうだとして、これは「masterブランチをとってこようとしたけどリモートには存在しなかったよ」という意味？

517 ：デフォルトの名無しさん：2011/10/31(月) 21:29:57.34

$ git tag
としたらタグの一覧が出てきますが、そのタグがどのコミットにつけられたのか知るにはどうしたらいいですか。
今は .git/refs/tags のなかを覗いていますが、さすがに別の方法があるはず。
でも git tag -h してもそれらしいオプションはないし。困りました。

518 ：デフォルトの名無しさん：2011/10/31(月) 21:42:56.10

git show タグ名

519 ：デフォルトの名無しさん：2011/10/31(月) 21:43:06.65

ローカルのタグを git push --tags でサーバ側にpushしたのですが、
別のマシンで git pull origin master や git fetch をしても、
.git/refs/tags が空のままで困ってます。
しかも、なぜが git tag すると、pushしたタグ名が表示されます (.git/refs/tagsが空なのになぜ？）
サーバ側にpushしたタグ名を、別のマシンにfetchしてくるにはどうしたらいいですか。

520 ：デフォルトの名無しさん：2011/10/31(月) 21:53:51.18

>>518
それはコミットとかのオブジェクトの中身を表示するコマンドですよね。
たしかにコミットIDも表示に含まれてますが、タグ名とコミットIDの一覧が表示できればそれでよくて、ファイルの中身とかは必要ないです。
ちょうど hg tags のように表示されればいいだけなんですけど、難しいでしょうか。

521 ：デフォルトの名無しさん：2011/10/31(月) 22:51:30.70

gitlab 試したヤシいる？
gitorious と比べてどうよ

522 ：デフォルトの名無しさん：2011/10/31(月) 23:09:06.91

>>517
タグだけ列挙する方法は俺も知らんので git-pack-refs して .git/packed-refs をかっさばけw

本末転倒だが git log --format='%H %d'

>>519
.git/packed-refs ができてないかどうかチェキ

523 ：デフォルトの名無しさん：2011/10/31(月) 23:11:24.52

つか、
GITDIR/refs/tags の一蘭をふつうに得る。
GITDIR/packed-refs の中身をかっさばく
べたにやっていいんではないかと。refs/tagsの方が優先な。

524 ：デフォルトの名無しさん：2011/11/01(火) 10:28:11.94

>>517
g log --decorate |grep "[ (]tag: "

じゃダメ？

525 ：524：2011/11/01(火) 10:31:19.82

あ、"g" は "git" ね
自分のalias書いちゃった

526 ：デフォルトの名無しさん：2011/11/01(火) 10:37:26.84

気にするな
俺もalias g=gitしてるｗ

527 ：デフォルトの名無しさん：2011/11/01(火) 10:52:38.06

refs の中覗くのも、

git log --decorate=full |grep "[ (]refs/"

でできるしね

528 ：デフォルトの名無しさん：2011/11/01(火) 11:15:25.18

>>527
これいいな
タグと各ブランチのHEADだけ一覧できる

529 ：デフォルトの名無しさん：2011/11/01(火) 15:56:50.07

貴様ら git-show-ref を忘れてるだろ！！！

530 ：デフォルトの名無しさん：2011/11/01(火) 17:12:34.96

>>529
マジで忘れてたw

つかコマンドとオプション多すぎなくない？

531 ：デフォルトの名無しさん：2011/11/01(火) 17:36:04.12

>>529
-d つけないとタグとコミットの対応わかんないし、どっちにしろ同じコミットでも
全部別々の行になっちゃうから、>>527のほうが俺は見やすいな

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

A-B-C
　　\-D

D の親は B になっているのを

A-B-C
　　　　\-D

親を C に変えるのは rebase D で行けるけど
これの逆に親が C だったのを B にするにはどうすればいい？

533 ：デフォルトの名無しさん：2011/11/01(火) 18:52:52.64

>>532
git rebase --onto B C D

534 ：デフォルトの名無しさん：2011/11/01(火) 22:56:08.88

コマンド体系まで二重管理

535 ：デフォルトの名無しさん：2011/11/01(火) 23:03:32.33

二重じゃないよplumbing porcelain cogit stgit tortoisegit

もちろんネタです

536 ：デフォルトの名無しさん：2011/11/01(火) 23:14:15.39

>>531
tagってtag objectのことだったのか。
--dereference で何が困るんだ?

537 ：デフォルトの名無しさん：2011/11/02(水) 14:55:42.99

git diffの結果を、ファイルか変更箇所ごとにマージするにはどうしたらいいんだろうか。

538 ：デフォルトの名無しさん：2011/11/02(水) 20:48:46.59

>>537
ファイルごとにaddしてcommitしてマージすればいいんじゃないの？違う？

539 ：デフォルトの名無しさん：2011/11/02(水) 21:16:28.81

patch当てたあとadd -pかね。

540 ：デフォルトの名無しさん：2011/11/03(木) 07:10:13.88

>>521
コレ読んでここでなんか話題が出てないかと思って来てみたけど
あなたしかレスしていないね
http://www.moongift.jp/2011/11/20111101-2/

541 ：デフォルトの名無しさん：2011/11/05(土) 18:24:22.73

Andoridアプリ開発しようと思ってeclipse落としたら
なんか最初からgit入ってるし
いつの間にかgitが主流になってきてるじゃねえか
まじやべえgitこわいよー

542 ：デフォルトの名無しさん：2011/11/05(土) 21:29:13.01

お前も二重管理の苦しみを味わうがよいｗ

543 ：デフォルトの名無しさん：2011/11/05(土) 22:05:47.33

eclipse, egit, jgit, cygwin, msysgit, tortoisegitの６重管理

544 ：デフォルトの名無しさん：2011/11/05(土) 22:10:46.58

ふらふらするなぎっとしろ。

545 ：デフォルトの名無しさん：2011/11/06(日) 05:23:22.52

gitでも高性能な機能を使わなかったら一重管理できるよね。
俺はブランチも切らずただひたすらcommit -allしてるだけだし。

546 ：デフォルトの名無しさん：2011/11/06(日) 08:59:10.87

高性能な機能と単純な機能の二重管理()笑

547 ：デフォルトの名無しさん：2011/11/06(日) 14:20:27.66

二重管理言いたいだけなんじゃないかと・・・。

548 ：デフォルトの名無しさん：2011/11/06(日) 15:19:13.05

何を今更

549 ：デフォルトの名無しさん：2011/11/06(日) 19:24:51.23

eclipseにデフォルトでcvsとgitは入ってるんだけどsvnは入ってないんだよね
svnってオープンソース界から嫌われてるの？

550 ：デフォルトの名無しさん：2011/11/06(日) 19:30:21.87

svnはコミット権を持つ者が支配層だからね。
そんな時代は終わりにしたいのさ。

551 ：デフォルトの名無しさん：2011/11/07(月) 20:44:28.91

ぎっとなの？じっとなの？

552 ：デフォルトの名無しさん：2011/11/07(月) 20:53:37.61

ぎっと、が一応正しい

「じっとはぶ」と読んでる人が大多数だと思うのだが、あれは「ぎっとはぶ」が正しい

553 ：デフォルトの名無しさん：2011/11/07(月) 21:00:54.00

＞「じっとはぶ」と読んでる人が大多数
それはない

554 ：デフォルトの名無しさん：2011/11/07(月) 21:07:00.25

>>551
http://ejje.weblio.jp/content/git

555 ：デフォルトの名無しさん：2011/11/07(月) 21:27:45.63

github は、周囲ではぎっはぶ (トが落ちる)が多いなぁ。
全く知らなかったらぎさぶ (thの発音で)と読んでしまいそう。

556 ：デフォルトの名無しさん：2011/11/07(月) 21:31:13.92

git
音節git 発音記号/git/

【名詞】【可算名詞】
《英俗》ばか者，ろくでなし.

557 ：デフォルトの名無しさん：2011/11/07(月) 21:49:47.47

じっとだろ

558 ：デフォルトの名無しさん：2011/11/07(月) 21:51:54.91

ギトって読んでるなぁ。GitHubはギトハブって・・・。

559 ：デフォルトの名無しさん：2011/11/07(月) 22:23:23.30

ギットでギットハブの俺にとってはこの流れがカルチャーショックなのだった。

560 ：デフォルトの名無しさん：2011/11/07(月) 22:23:39.37

おまいらもういいから
じっとしてなさい

561 ：デフォルトの名無しさん：2011/11/07(月) 22:37:11.41

git logだと増減したファイルのファイル名や修正されたファイルのファイル名が出ないのですが、
これを見るにはどうすればいいでしょうか？

562 ：デフォルトの名無しさん：2011/11/07(月) 22:42:58.04

git log --name-status かな。

563 ：デフォルトの名無しさん：2011/11/07(月) 23:05:44.39

まずは短めに --stat だな。

564 ：デフォルトの名無しさん：2011/11/08(火) 08:54:59.15

俺はwhatchangedよく使うな

565 ：デフォルトの名無しさん：2011/11/08(火) 10:33:50.10

特定のコミットに存在しないファイルを自動で消す方法ってないですか？

例えば linux kernel で v3.0.8 をコンパイルした後に
git checkout v2.6.32.46
とかした時に、v2.6.32.46に含まれない余分なファイル
を簡単に消す方法が知りたいです。

566 ：デフォルトの名無しさん：2011/11/08(火) 11:25:52.93

>>565
わかんないけど
rm -r *
git checkout v2.6.32.46
とか？

567 ：デフォルトの名無しさん：2011/11/08(火) 11:35:57.00

>>565
git clean -f
でなくて？

568 ：デフォルトの名無しさん：2011/11/08(火) 14:57:35.42

おれは心の中では、ギラハブ

569 ：デフォルトの名無しさん：2011/11/08(火) 15:03:09.65

>>567
うお、それそれ。これが見つかんなくて、>>566 と同じ事してて、
kernel treeだと、3万ファイル以上 checkout するんで
遅くて嫌になってたのよ。

助かったよ、ありがとう。
でも、>>530 じゃないけど、コマンドとオプション多すぎっつか、
逆引き git マニュアルとか欲しいよね。

570 ：デフォルトの名無しさん：2011/11/08(火) 15:13:36.72

ありゃ、ちょっと興奮して言葉遣いが荒くなってしまいました。
>>567の回答で助かりました。ありがとうございます。

571 ：デフォルトの名無しさん：2011/11/08(火) 19:39:46.04

git cheat sheet でぐぐって和訳して首吊って生き返れこんちくしょう

572 ：デフォルトの名無しさん：2011/11/08(火) 19:52:27.14

無罪！

573 ：デフォルトの名無しさん：2011/11/09(水) 07:47:05.98

addで追跡を開始したファイルの追跡をやめるにはどうすればいいでしょう。
ファイルを削除することなしで。

574 ：デフォルトの名無しさん：2011/11/09(水) 07:49:07.55

あ。すいません。すでにcommitされていてindexの中だけでなくリポジトリにも記録されてしまっているファイル
についての話です。

575 ：デフォルトの名無しさん：2011/11/09(水) 08:35:56.81

git rm --cached

576 ：デフォルトの名無しさん：2011/11/09(水) 12:31:18.15

gitむずい
新しいブランチを作ってリモートリポジトリに登録するには、これでいいの？

## ローカルブランチを作成
git co -b newbranch
## リモートブランチを作成
git push origin newbranch
## ローカルブランチとリモートブランチをひもづける
cat > .git/config
[branch "newbranch"]
　　remote = origin
　　merge = refs/heads/newbranch
^D

だれか助けて

577 ：デフォルトの名無しさん：2011/11/09(水) 18:37:44.12

>>576
git push -u origin newbranch

578 ：デフォルトの名無しさん：2011/11/09(水) 20:32:13.01

>>576
2重管理地獄で悶えて死ねｗｗｗｗ

579 ：デフォルトの名無しさん：2011/11/09(水) 20:33:36.22

MAJIRESU

多重管理できないSVN厨は trunk を物故わしてばっかり

580 ：デフォルトの名無しさん：2011/11/09(水) 23:52:17.86

なにこれ

581 ：デフォルトの名無しさん：2011/11/12(土) 22:47:10.16

svnみたいな集中型で、コミット権の無いリポジトリから改造版をつくろうとしたら
自分専用のリポジトリを使ってそこにソースコードをエクスポートして、改造版は別ブランチで管理するとか
そういう2重管理地獄に陥る

そうしてできた派生版リポジトリの変更を取り込もうとしたら
またソレ用のブランチ作ってそこにソースコード入れて・・・と3重管理4重管理の地獄行き

GitとかMercurialみたいな分散型なら自分用ブランチ作って、
本家の変更をマージ（リベース）するという形で管理できるのでより簡単
派生版の変更も同じようにマージできる

582 ：デフォルトの名無しさん：2011/11/15(火) 02:15:18.39

ディレクトリやファイルがたくさん含まれている中で、ただ1つのファイルだけを追跡したいのだが、
毎回ステージされていないファイル一覧が出てきて嫌だ。
目的のただ1つだけのファイルの他は全て無視するようにするにはどうすればいいだろうか。

583 ：デフォルトの名無しさん：2011/11/15(火) 02:20:00.42

.gitignoreに

/*
/.*
!/追跡したいやつ

1・2行目で全部無視にして、!付けて除外。

584 ：デフォルトの名無しさん：2011/11/15(火) 09:23:16.84

ありがとうございます。

.gitignoreファイルと、.git/info/excludeファイルはどのように使い分けていますか？

585 ：デフォルトの名無しさん：2011/11/15(火) 20:50:17.52

Ｇｉｔによるバージョン管理
2011/10
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5

実用Ｇｉｔ
2010/02
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8

入門Git
2009/9
http://www.shuwasystem.co.jp/products/7980html/2380.html

入門ｇｉｔ
2009/08
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

586 ：デフォルトの名無しさん：2011/11/15(火) 21:13:03.36

Gitによるバージョン管理は良い本だな
開発ストーリーに沿ってコマンドを紹介している章があって、理解しやすい

587 ：デフォルトの名無しさん：2011/11/15(火) 21:17:40.67

また新しいのが出たのかｗ
やっぱりみんな分かりにくいと思ってるんだよ

588 ：デフォルトの名無しさん：2011/11/16(水) 18:19:53.38

年に1冊ペースで本が出るのを「また」と称する感覚がよくわからない
ROM販売でいつ使ってもバージョンが固定されてるってわけじゃないし（Git2010とか）、
忘れ去られてない感じでいいじゃないかと思うんだが

589 ：デフォルトの名無しさん：2011/11/16(水) 19:20:12.05

ｃｖｓやｓｖｎはこんなにたくさん出てないだろ

590 ：デフォルトの名無しさん：2011/11/16(水) 19:44:57.94

>>589
ちょっと検索したけどＳＶＮの日本語の本は8冊出ている

591 ：デフォルトの名無しさん：2011/11/16(水) 21:50:37.87

サポート付きらしい。
https://github.com/git-book-version-control-ja/support

592 ：デフォルトの名無しさん：2011/11/16(水) 22:56:31.46

git svnでcloneして、色々書いてdcommitしたいんだけど、
その間適当なコメントでローカルにコミットしてたから、svnのlogには適当なコメントは反映させたくないんだ
どうしたらいい？

593 ：デフォルトの名無しさん：2011/11/16(水) 23:00:27.26

別ブランチ作って--squashでもすれば？

594 ：デフォルトの名無しさん：2011/11/16(水) 23:36:01.80

>>592
master は svn 追跡専用と割り切れ。
貴様 branch の上でせっせと禿んで dcommit の直前で squash.
dcommit 終わったら貴様 branch を rebase.

595 ：デフォルトの名無しさん：2011/11/16(水) 23:36:47.10

慣れたら branch 上でも svn dcommit を意識したコミットができるようになるってば。

596 ：忍法帖【Lv=8,xxxP】：2011/11/17(木) 00:00:53.17

「高橋麻奈　やさしいGit 」
まだ～？

597 ：デフォルトの名無しさん：2011/11/17(木) 07:38:45.76

>>593
>>594
ありがとう！助かった

>>595
まったく、おっしゃるとおりです。

598 ：デフォルトの名無しさん：2011/11/17(木) 19:50:03.75

Software Design 2011年12月号
http://gihyo.jp/magazine/SD/archive/2011/201112

第2特集
まだSubversionで大丈夫？
イケてるGitの使い方
［Git×Subversion＆Redmine］

第1章：SVN使いのための
Git入門……岡本隆史
第2章：git-svnによるSVN包囲戦［戦支度編］
ローカルGitでSubversionを攻略せよ……川西俊之，正徳巧
第3章：git-svnによるSVN包囲戦［実戦編］
ローカルGitでSubversionを攻略せよ……川西俊之，正徳巧
第4章：RedmineによるGitリポジトリ包囲戦
プロジェクト管理ツールでGitをパワーアップ……岡本隆史

599 ：デフォルトの名無しさん：2011/11/17(木) 20:09:10.16

岡村隆史と空目した・・・。

600 ：デフォルトの名無しさん：2011/11/17(木) 21:41:27.74

gitを使い続けていると精神が病むということ

601 ：デフォルトの名無しさん：2011/11/18(金) 01:24:02.17

>>595
それこそ慣れてからでいいんじゃねえの

602 ：デフォルトの名無しさん：2011/11/18(金) 01:24:55.20

>>598
Git×Subversion なんだな
Subversionのリポジトリで受けるの？

603 ：デフォルトの名無しさん：2011/11/18(金) 02:21:24.84

職場がsvnなんで、git-svnで自分だけgit使っているのですが
msysgit内蔵のsvnだと1.4.6でバージョンが古すぎてエラーになる
cygwinのgitだとsvnが1.7.1なので、新しめのsvnサーバーにもアクセスできるのですが
処理が遅すぎるのが微妙
vmwareでlinux起動してそこからgit-svnしたら安定して動くのですが
バージョン管理するためだけに仮想PC起動するのもだるい

git-svn使ってる人、みんなどうしてる？

604 ：デフォルトの名無しさん：2011/11/18(金) 06:29:45.83

git-svn 絡むときは windows ホストに git-svn させないようにしてるなあ。

605 ：デフォルトの名無しさん：2011/11/19(土) 11:37:31.30

作業領域からインデックスへのコミット
インデックスからローカルリポジトリへのコミット
ローカルリポジトリから中央サーバーへのコミット

の3重管理じゃねえかｗgitユーザーって馬鹿じゃないのｗｗｗ

606 ：デフォルトの名無しさん：2011/11/19(土) 12:04:17.69

頭悪そうな発言だ

607 ：デフォルトの名無しさん：2011/11/19(土) 12:49:17.01

ツールは使う人の能力次第

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

Gitは多重度次第w
ﾋﾞﾝﾀﾜﾘｰ

609 ：デフォルトの名無しさん：2011/11/19(土) 13:04:41.82

インデックスとかイラネだろ

610 ：デフォルトの名無しさん：2011/11/19(土) 13:24:23.65

インデクスはジャマだなーと思うことがある俺ガイル
歴史的には必要だっただろうけど

611 ：デフォルトの名無しさん：2011/11/19(土) 14:11:49.04

Gitのインデックスは後付けだが大発明だった。
インデックス使わないでどうすんの。

612 ：デフォルトの名無しさん：2011/11/19(土) 15:09:25.27

なんで中央のリポジトリを直接いじることをそんなに怖がってるんだろう
みんなで中央をどんどん更新していって間違いが入ったらすぐ直せばいいだけじゃん
中央に間違いが入らないようにするために3重管理地獄を選ぶとかどうかしてるぜ

613 ：デフォルトの名無しさん：2011/11/19(土) 15:30:22.79

作りかけはリポジトリにぶち込むか自分でtarでバックアップするかの二択
三重管理地獄とやらとどっちがいいのかね？

614 ：デフォルトの名無しさん：2011/11/19(土) 15:54:33.36

あ、もしかしてLinuxは全ビルドに何時間もかかるからってことなんかな
だったら小規模なソフトウェアでgit使ってるやつは馬鹿ってことになるな

615 ：デフォルトの名無しさん：2011/11/19(土) 15:56:40.22

>>614
小規模ソフトは身の程をわきまえてCVSってか？
お前に何を使えとか強要されたくないわ

616 ：忍法帖【Lv=40,xxxPT】：2011/11/19(土) 16:10:38.17

>>612
そういう発想だから理解できないんじゃないかと思うが? 中央のリポジトリを触るのが怖い訳ではないと思うぞw

617 ：デフォルトの名無しさん：2011/11/19(土) 16:25:19.93

え？

618 ：デフォルトの名無しさん：2011/11/19(土) 16:26:21.65

馬鹿には無理

619 ：デフォルトの名無しさん：2011/11/19(土) 16:55:52.77

　　　　　　　　　　　　 ,.　' ´ ￣￣￣￣￣｀ヽ、
　　　　　　　　　　／　　　　/　　　　　　　　　　＼　　　　
　　　　　　　　　 /　　　　　/　　　　　　　　　　　　＼
　　　　　　　　　/　　　　　/―――――――――ｲﾉ
　　　　　　　　/　　　　　/:　:　:　:　:　:　:　:　:　:　: :| |
　　　　　　　　,'　　　　,∠ ＿＿＿＿＿＿＿＿＿_/ |
　　　　　　　　|　　＜__:.:.イ:.｀メ､／|:/　|:./＼レ:.:.〈　|
　　　　　　　ﾉ!　　　　 |/ﾘﾚ',ｨｒそド"´　ﾚｨチxV:.!:.V}
　　　　　　／|　　　　/!:.:.! 〈. ﾄzリ　　　　ﾄzﾘ }:!::Ｎリ
　　　　　／　　　　　/ｿ:.:.ｉ　xx｀¨´　　　 ,　｀¨x{:从　}
　　　　/　　　　　　//|:.:.込、　　　　　　　　　/:.|.ハ∧　　　　
　　　 /　　　　　／厶|:.:.|＼ヽ、　　r つ　,. く:.:.:!　∧ ヽ
　　　/　　　／　　　|:.:.|::::::＞ミ　､　＜}　 |::.:|　　ヽ. }
　／i　　　〃　　　　ﾚ‐‐く＼　　￣´　/::!　 !:.:<フ二ヽﾘ
./　　　／/　　　　　/　／⌒く:＼　　イ:::::|　 |:. 厶--､　}
　　　/　/　　　　　（　　／,. ┤:::::ヽ /::::::|　 |:.厶--､　/

620 ：デフォルトの名無しさん：2011/11/19(土) 17:00:59.05

君じゃない。

621 ：デフォルトの名無しさん：2011/11/19(土) 18:36:03.97

>>611
hgにはインデックスとかないけど、拡張のmqとrecordがあれば特に困らないし

622 ：デフォルトの名無しさん：2011/11/19(土) 20:06:59.66

http://standing-shoebill.appspot.com/bzr-migration-docs/ja/survival/bzr-for-git-users.html
BazaarのUIレイヤには、インデックスに相当するものはありません。
Gitにあるような、部分的にコミットにステージングする機能はありません。
一部のファイルをコミットすることはできますし、プラグインを使えばファイル内の一部のハンクをコミットすることもできますが、コミットの一部をステージして作業を続ける方法はありません。

623 ：デフォルトの名無しさん：2011/11/19(土) 21:00:35.86

>>612
だから中央のリポジトリはコミットするのに査閲・承認が必要なんだって

あと管理表にない変数名を新規に定義することは許されないから
コミットする前に開発チームでローカルに命名した変数を
管理表にあるフォーマットに変換するリファクタリングのフェーズが必要だし。

624 ：デフォルトの名無しさん：2011/11/19(土) 21:09:50.44

おれも最初インデクスたん要らないしメンドクセーなとおもったが
git使い慣れたらこれの有り難みがわかった。

git嫌いな奴に無理にgit使えとは言わんから、わざわざこのスレ来て
ディスるのやめてくれませんかね。
SVNスレで勝手にSVNマンセーしててください。二度と来るな

625 ：デフォルトの名無しさん：2011/11/19(土) 21:12:25.91

＞だから中央のリポジトリはコミットするのに査閲・承認が必要なんだって
運用ルールの問題ジャン
git使っても同じことだろ

626 ：デフォルトの名無しさん：2011/11/19(土) 21:30:56.84

>>625
でもチーム内リポジトリをsvnでつくろうと思ったら結構な手間だよ。
いや、作ること自体は簡単だけど、チーム内と中央のリポジトリの整合をとるのが手間か。

627 ：デフォルトの名無しさん：2011/11/19(土) 21:52:47.20

チーム内リポジトリとかいらね
何で2重管理が前提条件になってるんだよ
直接中央コミットで問題起きたら即修正でなんら問題ないだろ

628 ：デフォルトの名無しさん：2011/11/19(土) 21:55:18.94

チーム内のはマイナーフィックスしたいときに容赦なくできるから便利ってことじゃないの？
で、メジャーフィックスを中央にコミットする。

629 ：デフォルトの名無しさん：2011/11/19(土) 21:57:23.13

>>627
>直接中央コミットで問題起きたら即修正でなんら問題ないだろ

でかい開発したことないだろ。
ちょっとした規模の開発でそんなことしてたら、収拾つかんぞ。

630 ：デフォルトの名無しさん：2011/11/19(土) 22:06:10.68

そもそもそうそう問題なんか起きないし
リポジトリ上のプログラムは常にビルドが通るようにしておくのが基本だろ
そんな簡単なこともgitユーザーはできないのｗ？

631 ：デフォルトの名無しさん：2011/11/19(土) 22:12:48.96

>>630
> そもそもそうそう問題なんか起きないし

小さい規模しかやったことがない奴の意見乙。

>リポジトリ上のプログラムは常にビルドが通るようにしておくのが基本だろ

ビルド通るだけでいいと思ってるのが君の想像力の限界なんだな。

632 ：デフォルトの名無しさん：2011/11/19(土) 22:18:21.85

Hello Worldしか書いたことないんじゃね？

633 ：デフォルトの名無しさん：2011/11/19(土) 22:19:41.91

Hello Worldの管理にはsvnがおすすめですよ＾＾

634 ：デフォルトの名無しさん：2011/11/19(土) 22:24:42.34

大規模ってどのくらいの規模のことを言ってるか分からんが
君らの言い分じゃ大規模開発じゃなければgitを使う利点ないわけね

635 ：デフォルトの名無しさん：2011/11/19(土) 22:28:06.26

svnは大規模にも小規模に使えて
gitは大規模にしか使えないうんこｗ

636 ：デフォルトの名無しさん：2011/11/19(土) 22:33:45.10

インデックスに登録するのは初めの一度だけで、あとはgit commit -all使えばいいだけなのに、
何をそんなに騒いでいるのか分からないなぁ。

637 ：デフォルトの名無しさん：2011/11/19(土) 23:26:44.54

>>627
いや、だから、何度も言うとおりコミットに査閲と承認が必要な環境があるんだよ

638 ：デフォルトの名無しさん：2011/11/19(土) 23:36:15.64

git使ったらコミットに査閲と承認が必要なくなるのかって。
それは運営方法の話だろ
バージョン管理システムの話してるんだけど馬鹿なの

639 ：デフォルトの名無しさん：2011/11/19(土) 23:55:06.16

TortoiseGitの1.7.5.0が出てた
もうバグが増えないといいな

640 ：デフォルトの名無しさん：2011/11/19(土) 23:55:17.27

チーム内のソース共有とかコードレビューの時にコミットが必要になるだろ
そんな時いちいち承認とかしてられないだろ
で、チーム内ローカルのリポジトリがあって、ひと通りのレビューが終わってから中央リポジトリにコミットすれば楽だろ
そういう時にチーム内ローカル→git 中央リポジトリ→svnだと管理が楽なんだよ
ローカルリポジトリをsvnにしてしまうと中央リポジトリへの反映が大変だし。

本当は中央リポジトリもgitにしてもらうか、承認を簡単にしてもらうほうがいいんだけど
中央は発注元だしあちらさんの社内文化を変えてもらう労力のが大変で、
gitの二重管理で自分たちだけ防衛したほうが工数少ないでしょうとかそんな色々な理由。

641 ：デフォルトの名無しさん：2011/11/20(日) 00:00:42.44

>>640
なるほど。参考になった。

642 ：デフォルトの名無しさん：2011/11/20(日) 01:48:49.24

Git していろ

643 ：デフォルトの名無しさん：2011/11/20(日) 04:26:03.72

SVN使いは、ビルド通らないソースをコミットするカスや
作業コピー以外で編集して他人のコミットを先祖返りさせるボケが
いるから嫌いなんだよな

ソース管理スキルに関していえば
Git使い＞＞＞（越えられない壁）＞＞＞SVN使い＞フォルダコピー使い

644 ：デフォルトの名無しさん：2011/11/20(日) 04:46:54.60

それだけ広く素人にも使われてるってことだろ
gitがsvnを超えて普及すれば同じ事言われるよ

645 ：デフォルトの名無しさん：2011/11/20(日) 08:33:26.23

>>644
もうgitはsvnを抜いているよ
http://qa.debian.org/popcon-graph.php?packages=bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion&show_installed=on&want_legend=on&beenhere=1

646 ：デフォルトの名無しさん：2011/11/20(日) 09:37:15.15

母数がDebianのパッケージマネージャって時点で、お前の言うカスやボケが含まれると思うか？

647 ：デフォルトの名無しさん：2011/11/20(日) 09:42:36.39

DebianはUbuntuとの２重管理のうんこ

648 ：デフォルトの名無しさん：2011/11/20(日) 09:46:27.84

>>645
インストールされていることと、使われていることの区別も付かんのか。

649 ：デフォルトの名無しさん：2011/11/20(日) 09:50:10.31

>>648
gitはインストールされているけど、使われていない、使えないのですね。わかります。

650 ：デフォルトの名無しさん：2011/11/20(日) 09:50:54.45

>716 ：デフォルトの名無しさん [↓] ：2011/11/20(日) 08:53:00.84
>コミットA→コミットB→コミットC
>
>上のコミットBに間違えてfoo.txtをaddしてコミットしまって今すごい周りに迷惑かけちゃってまして
>なんとかfoo.txtを自分のローカルのsvnの管理対象から除外して
>新しいコミットDからはfoo.txtがなかったようにしたいのですが、
>この場合どうすればいいんでしょう。。

svnユーザーの現実

651 ：デフォルトの名無しさん：2011/11/20(日) 09:58:58.43

Ａ，Ｂ，Ｃで3重管理してるのがそもそもおかしい

652 ：デフォルトの名無しさん：2011/11/20(日) 10:08:38.68

>>639
それよりmsysgitのsvnが古いのを何とかしてほしい
svnが1.7で互換性をブチ切ったりしなけりゃ古いままでも問題なかったんだが

653 ：デフォルトの名無しさん：2011/11/20(日) 10:53:57.35

無料RPG製作ツール「ロープレジェネレーター」

直感的操作で簡単なゲームが作れます。簡単に配布可能な状態に出力する
ことができます。(HSP製のソースコード付きで、スクリプトの知識があれば
自由度の非常に高いカスタマイズができます）
他にも仲間預かり機能（100人も）や、仲間の状態/状態異常を細かく設定
できたり、乗り物が作れたり、ゲーム中に画像を差し込んだり、回転や
フラッシュなどのエフェクトなんかも簡単に作れる様です。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
戦闘はデフォだとドラクエ系。

・次期バージョンのロープレジェネレーター2.00アルファ版2を公開しました。(2011/10/29)

654 ：デフォルトの名無しさん：2011/11/20(日) 12:48:41.16

>>651
>Ａ，Ｂ，Ｃで3重管理してるのがそもそもおかしい

３重管理？

655 ：デフォルトの名無しさん：2011/11/20(日) 17:09:38.33

Gitで多重管理とかって何のこと指してんだろ

656 ：デフォルトの名無しさん：2011/11/20(日) 18:01:31.77

もはや多重管理言いたいだけちゃうんかと

657 ：デフォルトの名無しさん：2011/11/20(日) 19:00:05.40

そもそも分散リポジトリ使ってて、めんどくさいと感じたことなんかないんだが。
むしろ馬鹿が中央リポジトリにヘンなのコミットしても
自分とこだけは一時的に防衛できるので作業効率よくなった

658 ：デフォルトの名無しさん：2011/11/20(日) 19:15:59.00

うるせえ、「重管理」NGワードにすっぞ

659 ：デフォルトの名無しさん：2011/11/20(日) 19:16:42.95

あ、>>657に言ってるんじゃないので

660 ：デフォルトの名無しさん：2011/11/20(日) 19:24:18.13

>>658
してなかったのかよ、NGワード多重管理君。

もちろんもはやn重管理はネタだろ。

661 ：デフォルトの名無しさん：2011/11/20(日) 19:31:15.27

NGワード指定するほどレスないだろ、この板。

662 ：デフォルトの名無しさん：2011/11/20(日) 21:07:34.76

Linuxのカーネルとかだと100重管理ぐらいいってるかな?w

663 ：デフォルトの名無しさん：2011/11/20(日) 21:46:50.54

>>662
９９重=苦渋苦渋管理

664 ：デフォルトの名無しさん：2011/11/20(日) 23:26:00.19

ぐしゅぐしゅ。

発狂しそうなパッチ・版多重管理をこなせたのがBKで
それの跡を継いだのがGitだろ?

ただ、CVS/SVNを経験してGitに慣れたヤツがSVNに戻れるか? と言われたら
例外なく戻れないだろう。反例求む。(SVN反Git厨は釣られないように)

665 ：デフォルトの名無しさん：2011/11/21(月) 00:34:15.31

周りに合わせざるを得ないので svn はまだ使ってる
git svn は糞なので使えない

666 ：デフォルトの名無しさん：2011/11/21(月) 01:28:49.87

戻れるかと言ったら普通に戻れるけど、利点はないな。
強いて言えば日本語の対応とか。

667 ：デフォルトの名無しさん：2011/11/21(月) 02:41:12.64

戻るメリットっていったら、日本語ファイル名が正しく使えることくらいか
あとはWindowsで使うときにはSubversionのがすこし安定してる気がする

しかしそんだけのために戻る気はしないな

668 ：デフォルトの名無しさん：2011/11/21(月) 12:35:59.44

たすけてください
git commit -m "test"
で間違えてコミットしてしまったのを取り消したくて
git revert HEAD
としたのですが
取り消しを取り消したい場合はどうしたらいいのでしょうか？

git revert HEADの後ににファイルを編集したので
もう一度コミットするとおかしくなってしまいますのでたすけてください

669 ：デフォルトの名無しさん：2011/11/21(月) 12:42:59.04

とりあえずdiffとっといてgit reset --hardで、問題ないとこまで戻るとか
状況はわからんけど、やりようはいくらでもありそう

670 ：デフォルトの名無しさん：2011/11/21(月) 13:14:26.61

ProGitみたいな親切なドキュメントあるのに読まない奴ってなんなの？

671 ：デフォルトの名無しさん：2011/11/21(月) 13:26:31.67

管理の仕方についてアドバイスお願いします
C:\sourcecode\python
C:\sourcecode\ruby
C:\sourcecode\perl
とあります

これら言語別にフォルダ分けがされており、フォルダの中にもまたプロジェクトごとにフォルダが分けられてます
C:\sourcecode\python\helloworld
C:\sourcecode\python\mywiki
C:\sourcecode\python\mycms

こういう場合リポジトリを作成する場合は
コマンドプロンプトでC:\sourcecodeをカレントディレクトリにしてgit initをするものでしょうか？
それとも書くプロジェクトごとにgit initをするものでしょうか？

672 ：デフォルトの名無しさん：2011/11/21(月) 13:48:26.47

>>668
git revert HEAD をもう一度。

という身も蓋もない回答は置いといて
git log とか git reflog して、戻したい場所を見つけたら
git reset (所望のsha1)

git reset が怖かったら
git checkout -b tekitouna_ichijitekina_branch (戻したいsha1) だ。
俺はこの手合いの作業は detached branch 上でやっちゃうけどなw

673 ：デフォルトの名無しさん：2011/11/21(月) 13:50:00.33

>>671
全部まとめてひとつのリポジトリにしてしまうのが、さしあたっての管理は楽。
git-submodule という機構もあるが、初心者が使うとぜったい事故る。

674 ：デフォルトの名無しさん：2011/11/21(月) 15:18:01.46

>>664
mergeしない・branchしないってわかってる用途限定ならsvnに戻れる
他に大きな理由がなければ戻りたくはないが

675 ：デフォルトの名無しさん：2011/11/21(月) 16:03:18.66

リモートリポジトリからファイルを取得するときに

git clone C:\test\. ってやってるんですが
ローカルのディレクトリに一つでもディレクトリやファイルがあるとエラーになるので毎回ローカル側のファイルやディレクトリ(.gitも含む)を消してからcloneを実行してます
こういうものなんですか？

676 ：デフォルトの名無しさん：2011/11/21(月) 16:39:04.24

それfetchとかpullとかするところ。cloneは初回だけ。

677 ：デフォルトの名無しさん：2011/11/21(月) 16:42:47.68

>>675
そんなものではない。
git clone した後は、簡単な場合 git pull とか git fetch & git merge で済む。
(ついでにいうと pull とか fetch はそれなりに速い)

git clone C:\test\. って git clone (URL) C:\test\. の間違いだよな?

678 ：デフォルトの名無しさん：2011/11/21(月) 16:46:22.05

>>676
いろいろコマンドがあるんですね
ちょっとその単語で練習してみます

>>677
すいませんcdを載せ忘れました
本来は
cd C:\local
git clone C:\test\.
です

679 ：デフォルトの名無しさん：2011/11/21(月) 16:46:25.72

>>664
commit もしない、ローカルでの変更もしない、だったら戻れなくもないが俺何か道を間違えてるよな。

680 ：デフォルトの名無しさん：2011/11/21(月) 18:08:54.19

>>674
svnでbranchしたら二重管理になっちゃうだろ！

681 ：デフォルトの名無しさん：2011/11/21(月) 18:15:31.26

>>680
svnにbranchはありません

682 ：671：2011/11/21(月) 22:19:49.69

>>673
間違えてへんなことして全部まとめて逝ったら困るので最初は分けて管理して見たいと思います

リモートリポジトリ (Dドライブ)
D:\sourcecode\python
D:\sourcecode\ruby
D:\sourcecode\perl

ローカルリポジトリ (Cドライブ)
C:\sourcecode\python
C:\sourcecode\ruby
C:\sourcecode\perl

MSDOS上からやったこと
cd D:\sourcecode\python
git --bare init
cd C:\sourcecode\python
git init
git add .
git commit -m "1"
git push D:\sourcecode\python master
git remote add origin D:\sourcecode\python
とやってpython用のを作りました,ruby用とperl用も同じようにして作りました
ここで疑問なんですが
git pushってやるとローカルリポジトリのデータがリモートリポジトリに反映されますが
これはgitを実行したカレントディレクトリを見て、どこにpushするか自動判別しているのでしょうか？
例えばpython用のところでgit pushってしたらperl用の所にpushされてしまうってことはございませんか？

683 ：デフォルトの名無しさん：2011/11/21(月) 23:24:53.83

git remote -v ってやってみろ

684 ：デフォルトの名無しさん：2011/11/22(火) 00:25:19.63

remote が　remove に見えた。セフセフ。

685 ：671：2011/11/22(火) 11:31:56.18

あれ？pythonのフォルダでgit remote -vってやったら
origin D:\sourcecode\python (fetch)
origin D:\sourcecode\python (push)
って出ました
rubyとperlでもやったらちゃんと別々になりました
gitってどのカレントフォルダでコマンドを実行したかで自動でpush先を選択してくれるんですね！
今までバージョン管理って怖くていつもzipで全部固めてたんですが(サイズが832MBぐらい)
git使うとHDDの寿命も延びそうだし楽なのを覚えました

686 ：デフォルトの名無しさん：2011/11/23(水) 04:24:25.98

.git/objects以下ってコミットするごとにファイル増えていくと思うんだけど、
どの位まで性能でるの？

687 ：デフォルトの名無しさん：2011/11/23(水) 07:43:49.07

>>686
git gc

688 ：デフォルトの名無しさん：2011/11/25(金) 22:19:44.08

復帰

689 ：デフォルトの名無しさん：2011/11/26(土) 12:44:07.29

subversionからgitへ移行しています。
ちょっと解らないところがあるので教えてください。

webアプリを開発していて、開発用ブランチと本番環境用ブランチを作成して作業しています。

開発用ブランチに開発用のコード(DB設定やデバッグ用コード)を記述したとき、
subversionでは merge --record-only を使用してそのコードが本番環境にマージされない様にしていました。

git の場合はどのように処理すればいいのでしょうか？

今は本番環境にマージするときに --no-commit を指定して手作業で開発用コードを削除しているのですが、
本番環境から開発環境へマージするときに、今度は開発用コードが削除されます。

いい手があればアドバイスいただけませんか。

690 ：デフォルトの名無しさん：2011/11/26(土) 14:43:17.03

>>689
db設定やデバッグ用のエラー出力on/offとかは
アプリケーションの設計時に一つのiniファイルかなんかにまとめるようにしてignore
その他の実験用コードは開発用ブランチからのブランチで隔離実験ってのが基本じゃないですか？

691 ：デフォルトの名無しさん：2011/11/26(土) 14:53:42.70

>>689
Subversionの「マージ」という言葉を忘れよう。
あれはマージとは言わない。
Gitで言う所のcherry-pick。
Gitのスマートなマージが理解できたら、自然と運用ルールが定まるだろう。

692 ：デフォルトの名無しさん：2011/11/26(土) 20:03:39.46

>>689
環境設定はテンプレだけコミットしておいて実行環境に合わせて別のignoreするファイルに
追い出しておくのがいいと思う。それかコミットする環境設定ファイルは常に本番用に保って
おいて各自はデプロイで上書きするとか。
どこかの開発環境の設定でコミットとか、人によっては激怒するぜ。。。

あとsvnってmergeinfoとかいうのが出来たのか。svkみたいなもん？

693 ：689：2011/11/28(月) 17:01:46.95

アドバイスいただきありがとうございます。

subversionと同じような運営の仕方はできないのですね。
iniファイルの仕様変更とか入ったときに管理しやすいし、
設定項目が多い場合なんかは便利だったんですが。

> どこかの開発環境の設定でコミットとか、人によっては激怒するぜ。。。
ブランチ切って merge --record-only しておけば、
それを防ぎつつ設定ファイルまで管理できてたんです。

> あとsvnってmergeinfoとかいうのが出来たのか。svkみたいなもん？
svk見たいな外部ツールとは違い、標準で組み込まれた機能です。
マージしたときにどのリビジョンをマージしたかがプロパティに記録されるので、
次回マージするときにマージ済みの分は自動でスキップされます。

694 ：デフォルトの名無しさん：2011/11/29(火) 12:11:28.27

>>693
本番環境から開発環境へのマージはどういう変分を反映させることを期待しているのだろう？

695 ：689：2011/11/29(火) 17:48:42.12

>>694
開発環境でのテストでは問題なかったのに、
本番環境へ持っていったら動かなかった場合、
本番環境上で直接修正を行う場合があります。

あとは、客先の担当さんが直接変更を加える場合があるので、
それを取り込む場合があります。

その場合、本番ブランチに一旦コミット後、開発ブランチへマージ、
機能修正等を行ったあと本番ブランチにマージといった流れでやってます。

696 ：デフォルトの名無しさん：2011/11/29(火) 18:24:52.29

>>695
Gitスレで運用の話をしても満足する回答はないよ。総合スレ行ったら？
Git/Mercurial/BazaarはDAGだから、Subversionと同じ感覚だと違和感があるよ。
それこそ>>664のようにSubversionに戻れなくなるから。

697 ：デフォルトの名無しさん：2011/11/29(火) 23:36:55.67

なんかデスマテンプレートみたいな運用だな
確かに本番だけ動かん、というケースは存在するし、
結果的にぶっつけで本番直すことあるが、
根本的に手順が間違ってる。

スレチすまん。

698 ：デフォルトの名無しさん：2011/11/29(火) 23:38:41.40

＞マージしたときにどのリビジョンをマージしたかがプロパティに記録されるので、
＞次回マージするときにマージ済みの分は自動でスキップされます。

いつの間にかsubversionのマージも進化してたんだな
俺が使ってた頃はリビジョン範囲指定しなければならなくて
使いづれーなっておもってた

調べてみたら各フォルダにsvnができるのも改善されたんだな

699 ：デフォルトの名無しさん：2011/11/30(水) 00:25:39.28

>>693
開発ブランチから本番ブランチへは cherry-pick、
その後開発ブランチで本番をマージ。
もしくは開発ブランチでrebaseしてマージで持っていきたくない
履歴を先頭に追いやる。

てか何でろくにドキュメント読まずに移行しようとするんだ。
「svnのように」使いたいなら無理せずsvn使っとけば？

700 ：デフォルトの名無しさん：2011/11/30(水) 01:31:03.11

>>695
>451のリリースブランチってのを参考にするとよい。
svnで本番ブランチに直接コミットすることが間違っているとは思うが。

701 ：デフォルトの名無しさん：2011/12/02(金) 23:55:59.23

>>699,700
>451のモデルと合わせて考えれば
・開発ブランチからリリースブランチを作るときにcherry-pickでリリース対象のコミットだけ分離
・本番ブランチへリリースブランチをマージするときに開発ブランチへもマージ
で目的を果たせそうだな
一度除外したデバッグコミットは次のリリースからは含まれないし、デバッグコミットのログルールを決めておけば、cherry-pickも自動化出来そう

702 ：デフォルトの名無しさん：2011/12/03(土) 02:41:56.10

>>701
ほんとにクソみたいなデバッグログは add -p で除外して stash に溜め込むか、
デバッグのコミットを一個作って rebase してる。
あんま激しくなってくると rebase でコンフリクトしちゃんだけどね。

703 ：デフォルトの名無しさん：2011/12/10(土) 04:42:14.03

閑古鳥がないてますなあ
いまのバージョンでも十分安定してるし、機能不足も感じないから
話題がないか

704 ：デフォルトの名無しさん：2011/12/10(土) 04:55:30.66

普通に使えてるし特に言うことないな

705 ：デフォルトの名無しさん：2011/12/10(土) 09:12:25.29

外注先の奴らに使わせるには日本語がまともに使えることとGUIが必要だな

706 ：デフォルトの名無しさん：2011/12/10(土) 09:57:42.87

>>705
日本の外注を使わなければ良いだけの話

707 ：デフォルトの名無しさん：2011/12/10(土) 10:10:42.81

SCM のために、慣れないなんちゃって英語でバグ作りこまれた上に
レビューもろくろくできなくなるなんて愚を犯す奴は馬鹿でしょ。

708 ：デフォルトの名無しさん：2011/12/10(土) 10:23:10.61

>>707
日本人のレビューアーが馬鹿なだけでしょ。
インド人は英語うまいよ。

709 ：デフォルトの名無しさん：2011/12/10(土) 10:38:03.77

ここは、日本で発注者も日本人だって客に言われたら、
SCM の都合でできませんって答えるのか？

馬鹿だろ。

710 ：デフォルトの名無しさん：2011/12/10(土) 10:43:30.68

gitが使えない外注先が淘汰されるのに何が問題なわけ？

711 ：デフォルトの名無しさん：2011/12/10(土) 10:45:51.46

問題の理解力もないところの人でしたか、それは失礼。
まあ、せいぜい git で遊んでてください。

712 ：デフォルトの名無しさん：2011/12/10(土) 10:46:56.91

分散型普及の壁になっているのは外注より元締め。
開発者は今でもgit-svnとか使っている。

713 ：デフォルトの名無しさん：2011/12/10(土) 10:49:06.75

>>711
コミットログは日本語使えるし、GUIはEclipseとか揃っているし、
日本語が問題になるのはWindowsのファイル名だけでしょ。
これのどこが問題なわけ？

714 ：デフォルトの名無しさん：2011/12/10(土) 11:31:51.25

>>713
>日本語が問題になるのはWindowsのファイル名だけでしょ。
>これのどこが問題なわけ？

自分で「問題になるのは」って書いてて、「どこが問題？」って頭おかしいのか？

715 ：デフォルトの名無しさん：2011/12/10(土) 11:38:51.42

>>714
Windowsのファイル名が問題になるのだったら、それまでのプロジェクトが問題であって、
その問題を解決すれば問題にならない。

716 ：デフォルトの名無しさん：2011/12/10(土) 11:51:41.61

だからお客さんの都合だとどうしようもないだろって書いてるんだが、
やはり理解力が相当足りないみたいだな。

717 ：デフォルトの名無しさん：2011/12/10(土) 11:56:32.91

windows のファイル名に日本語が使えないと致命的に駄目

718 ：デフォルトの名無しさん：2011/12/10(土) 11:58:29.94

>>716
お客さんが日本語ファイル名ファイルをscmで管理するように要求しているのか？
ならば、そのファイル名ファイルだけ、日本語ファイル名で問題無いと思われているscmのままにしておけば良いじゃないか。
それ以外のところはgitに移行して何ら問題ないわけだ。

719 ：デフォルトの名無しさん：2011/12/10(土) 12:12:37.52

git のために、別々に管理しろって？
構成管理理解してない馬鹿のたわごとだな。

720 ：デフォルトの名無しさん：2011/12/10(土) 12:18:50.13

>>719
svnのように全部一ヶ所にまとめろって？
危機管理理解していない馬鹿のたわごとだな。

721 ：デフォルトの名無しさん：2011/12/10(土) 12:26:04.23

Bazaar の出番ですね。

722 ：デフォルトの名無しさん：2011/12/10(土) 12:39:21.56

そもそも受託開発なんて底辺仕事なんざ興味ねぇよ
底辺は勝手にやってろよ

723 ：デフォルトの名無しさん：2011/12/10(土) 12:43:04.80

受託開発の底辺はsvnの一元管理で悶えて市ね

724 ：デフォルトの名無しさん：2011/12/10(土) 12:44:39.02

多重管理地獄で悶えて氏ね

725 ：デフォルトの名無しさん：2011/12/10(土) 13:34:09.63

>>720
>危機管理理解していない馬鹿のたわごとだな。

別地保管も知らんのか...。
git だと分散だからと言ってバックアップもイラネーとか言い出したりしてな。(w

>>722-723
はいはい、こんな馬鹿なところじゃ受託すらできんわな。(w

726 ：デフォルトの名無しさん：2011/12/10(土) 13:41:07.33

>>725
危機管理＝バックアップだという認識なのか、おめでたいな

727 ：デフォルトの名無しさん：2011/12/10(土) 13:43:09.53

>>725
> 別地保管も知らんのか...。
svnで別置保管がどうすれば可能なのか教えてくれ

728 ：デフォルトの名無しさん：2011/12/10(土) 13:53:20.51

>>725
> git だと分散だからと言ってバックアップもイラネーとか言い出したりしてな。(w
hgだと要らないね。落ちた前スレで議論されている。
gitの場合、ブランチを消せるから全く要らないわけではないが。

729 ：デフォルトの名無しさん：2011/12/10(土) 14:18:52.99

>>726
>危機管理＝バックアップだという認識なのか、おめでたいな

じゃあどういう意味か書いてみな。

>>727
適当なデータセンタに電話して聞いてみればいいと思うよ。
うちは、支社があるから自社でやってるけど。

>>728
> hgだと要らないね。

まだ、こんなこと言ってるアホがいるのか...。

730 ：デフォルトの名無しさん：2011/12/10(土) 14:24:26.86

>>729
> >>726
> >危機管理＝バックアップだという認識なのか、おめでたいな
> じゃあどういう意味か書いてみな。
Linusがsvnを叩いた講演。
どこかの馬鹿が馬鹿なコミットをすることを防ぐこと。

> >>727
> 適当なデータセンタに電話して聞いてみればいいと思うよ。
> うちは、支社があるから自社でやってるけど。
svnだとデータセンタが必要なわけね。
分散型ならそんなの必要ない。

> >>728
> > hgだと要らないね。
> まだ、こんなこと言ってるアホがいるのか...。
アホはおまえだ。
hgは全リビジョン同期でリビジョンの削除はしないから、
同期されていれば、バックアップなど必要ない。

731 ：デフォルトの名無しさん：2011/12/10(土) 14:52:26.47

>>730
>どこかの馬鹿が馬鹿なコミットをすることを防ぐこと。

まともな運用もできていない組織だとツール側で必要なんだろうな。

>>727
>分散型ならそんなの必要ない。

結局複数サーバーで管理するってことだろ？
まさかとは思うが、ローカルにあるからいいジャンとか本気で言ってそうだな。

>>728
>同期されていれば、バックアップなど必要ない。

管理者のミスとか SCM 自体のバグとか考えたこともないんだろうな...。
素人乙。

732 ：デフォルトの名無しさん：2011/12/10(土) 15:03:19.66

>>731
> >>730
> >どこかの馬鹿が馬鹿なコミットをすることを防ぐこと。
>
> まともな運用もできていない組織だとツール側で必要なんだろうな。
外注先、オフサイトで馬鹿なコミットされるの防ぐために、
わざわざコードレビューしに出張するわけか。
高コストなこと。

> >>727
> >分散型ならそんなの必要ない。
>
> 結局複数サーバーで管理するってことだろ？
> まさかとは思うが、ローカルにあるからいいジャンとか本気で言ってそうだな。
分散型にサーバという概念はありませんが？

> >>728
> >同期されていれば、バックアップなど必要ない。
>
> 管理者のミスとか SCM 自体のバグとか考えたこともないんだろうな...。
> 素人乙。
gitにバグがあったらLinuxはこの世に存在していないけど。
分散型の管理者って誰？
git/hgはリポジトリフォーマットはほとんど変わっていないけど、
その論理だと、リポジトリフォーマットが頻繁に変わるsvn/bzrなんか使ってられないね。

733 ：デフォルトの名無しさん：2011/12/10(土) 15:21:41.82

>>732
>わざわざコードレビューしに出張するわけか。

TV会議システムもない職場乙。

>分散型にサーバという概念はありませんが？

まさかの方だったな。(w

>gitにバグがあったらLinuxはこの世に存在していないけど。

今までがよかったからこれからも大丈夫って言うわけね。
笑うしかないが。

>その論理だと、リポジトリフォーマットが頻繁に変わるsvn/bzrなんか使ってられないね。

意味不明。

734 ：デフォルトの名無しさん：2011/12/10(土) 15:33:01.54

>>733
> TV会議システムもない職場乙。
TV会議システムがないと品質も保証されない職場乙。

> >gitにバグがあったらLinuxはこの世に存在していないけど。
> 今までがよかったからこれからも大丈夫って言うわけね。
> 笑うしかないが。
大丈夫。
分散型を理解していないみたいだからこれ以上説明しても無駄みたいだけど。
それよりもsvnの将来心配したら？

> >その論理だと、リポジトリフォーマットが頻繁に変わるsvn/bzrなんか使ってられないね。
> 意味不明。
svnのbdbが壊れやすかったって知らないのね。
svn1.7でまた変わったんじゃないの？使ってないから知らないけど。
バージョンアップしたら過去のバックアップが使えないんだったら、
バックアップの意味ないけど。

735 ：デフォルトの名無しさん：2011/12/10(土) 15:46:48.50

>>734
>TV会議システムがないと品質も保証されない職場乙。

ひょっとして貧乏会社なの？
最近結構まともな奴が安いから入れたら？

>大丈夫。

それは、よかったな。
まあ、ビジネスに使ってないこと祈るよ。

>svnのbdbが壊れやすかったって知らないのね。

そうだね、壊れやすかったな。アホが使うと。
申し訳ないが、うちでは壊れたことはないよ。
そもそも今時 bdb なんて使ってないし。

>バージョンアップしたら過去のバックアップが使えないんだったら、
>バックアップの意味ないけど。

馬鹿は bdb は知ってるのに svndump には思いが至らないらしい。
まあ、よくいる中途半端な知ったかなんだろうな。

736 ：デフォルトの名無しさん：2011/12/10(土) 15:52:43.55

>>735
> >>734
> >TV会議システムがないと品質も保証されない職場乙。
>
> ひょっとして貧乏会社なの？
> 最近結構まともな奴が安いから入れたら？

日本人は欧米とTV会議するため毎日夜勤ですか。
お疲れ様です。

>
> 馬鹿は bdb は知ってるのに svndump には思いが至らないらしい。
> まあ、よくいる中途半端な知ったかなんだろうな。
あなたのその理屈だと、そのsvndumpにバグがあったらどうするの？
svndumpが動いていると信じていたら実は取れていませんでした、
ってそれこそ管理者のミスを心配しないと。

737 ：デフォルトの名無しさん：2011/12/10(土) 16:02:20.75

なんか盛り上がってるところ水を差すようだけど
野良パッチ使えばwindowsのgitでも日本語ファイル名使えるんだけどね

GUIしか使えないとかいう馬鹿を除けば、現状で全く問題ない

738 ：デフォルトの名無しさん：2011/12/10(土) 16:06:11.50

>>737
野良パッチどころか、msysgitはutf-8対応に向けて驀進中です

739 ：デフォルトの名無しさん：2011/12/10(土) 16:56:00.57

>>736
>日本人は欧米とTV会議するため毎日夜勤ですか。

必死に考えたんだね、お疲れ。
まあ、普通に定時間内にできてるから、心配しなくていいよ。

>svndumpが動いていると信じていたら実は取れていませんでした、
>ってそれこそ管理者のミスを心配しないと。

バックアップ取ったら、リストアのテストするのは常識なんだが...。

740 ：デフォルトの名無しさん：2011/12/10(土) 17:05:40.58

>>739
> >日本人は欧米とTV会議するため毎日夜勤ですか。
> 必死に考えたんだね、お疲れ。
> まあ、普通に定時間内にできてるから、心配しなくていいよ。
日本人は深夜が定時間か。
24時間営業のファミレス・マクドナルドのような勤務体制なわけだ。

> >svndumpが動いていると信じていたら実は取れていませんでした、
> >ってそれこそ管理者のミスを心配しないと。
>
> バックアップ取ったら、リストアのテストするのは常識なんだが...。
バックアップ・リストア、そのテストと、凄い高コストだ。

741 ：デフォルトの名無しさん：2011/12/10(土) 17:38:52.59

>>740
>日本人は深夜が定時間か。

正直君がかわいそうになってきたよ。
自分で書いてて恥ずかしくない？

>バックアップ・リストア、そのテストと、凄い高コストだ。

まあ、必要なコストだからね。
そもそもこの手のコストが高いと感じているってことは、
他もいろいろ手を抜いているんだろう。
たぶん素人さんだと思うけど。

742 ：デフォルトの名無しさん：2011/12/10(土) 17:44:58.30

普通に質問なんだけど、みんなレポジトリのバックアップってどうとってる？

743 ：デフォルトの名無しさん：2011/12/10(土) 17:46:11.15

>>741
svnを使っている所は分散型で必要ない膨大なコストをかけている
ボッタクリだってことが分かったから、今度から発注することはやめるよ。ありがとう。

744 ：デフォルトの名無しさん：2011/12/10(土) 17:57:48.05

>>743
はいはい、こういう脇の甘い馬鹿なところから受注するのは実はおいしいんだが、
疲れるのも事実だから、今後は是非そうしてくれ。(w

745 ：デフォルトの名無しさん：2011/12/10(土) 18:05:45.88

>>742
svnadmin dump

746 ：デフォルトの名無しさん：2011/12/10(土) 18:07:10.49

githubに上げてる

747 ：デフォルトの名無しさん：2011/12/10(土) 18:31:36.41

>>742
誰かの説によると、分散型なら不要らしいよ。(w

一応ご参考: http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/chunked/ch07.html

>>745
git のスレだぞ。

748 ：デフォルトの名無しさん：2011/12/10(土) 18:36:26.68

盛り上がってますね

749 ：デフォルトの名無しさん：2011/12/10(土) 18:46:02.52

>>742
他のサイトからたまにfetchしてる

750 ：デフォルトの名無しさん：2011/12/10(土) 18:56:01.17

他人と共同で作業する為に中央にリポジトリ作る時点で分散型でもなんでもない単にリモートとローカルで２重管理してるだけｗ

751 ：デフォルトの名無しさん：2011/12/10(土) 18:56:17.42

スレの流れがよく読めんのだが
ソースコード(C#やJava)とかDBファイル(.sqliteとか)の名前に日本語使うのはよくあることなのか？

752 ：デフォルトの名無しさん：2011/12/10(土) 19:02:34.05

>>750
分散型という名前に惑わされている典型的バカ。
ワークフローの方が重要だという勉強をしてから出直しましょう。
http://www.ustream.tv/recorded/18604921

753 ：デフォルトの名無しさん：2011/12/10(土) 19:02:56.93

底辺とか事実を指摘するもんだから発狂しちゃっただろ

754 ：デフォルトの名無しさん：2011/12/10(土) 19:03:21.65

>>751
無いよね。だからドキュメント類だけsvnとかに置けば良いと思う。
エクセルとかパワポとかどうせマージできないしね。

755 ：デフォルトの名無しさん：2011/12/10(土) 19:30:31.82

定期的にfetchしとけばバックアップとしてはいいのかな？
あれ、トラックしてないブランチはfetchされない？

756 ：デフォルトの名無しさん：2011/12/10(土) 19:32:12.24

>>754
また、>>719 からループするの？
いい加減諦めたら？

757 ：デフォルトの名無しさん：2011/12/10(土) 19:35:42.62

諦めるのは底辺の仕事しか無い自分の人生では？

758 ：デフォルトの名無しさん：2011/12/10(土) 19:46:58.39

底辺に馬鹿にされてる君の人生って...。(w

759 ：デフォルトの名無しさん：2011/12/10(土) 19:55:01.35

君って何人？この板は連投規制があったはずだけど。

760 ：デフォルトの名無しさん：2011/12/10(土) 20:06:37.49

自分の胸に聞いてみればわかるんじゃない？

761 ：デフォルトの名無しさん：2011/12/10(土) 20:11:26.50

自分の胸に聞いてみた。svn使いは馬鹿だって言っていた。

762 ：質問の内容とぜんぜん違う答えで納得している馬鹿。：2011/12/10(土) 20:21:37.61

それはよかったね。(w

763 ：デフォルトの名無しさん：2011/12/10(土) 22:16:38.37

svn で満足できるなら git 使える人達をうらやましがってこのスレを荒らさずに自分の領分で満足してればいいと思う(´･ω･`)

764 ：デフォルトの名無しさん：2011/12/10(土) 22:43:18.54

msysGitがUTF-8対応するなら、もうsvn使うメリットは皆無だな・・

765 ：デフォルトの名無しさん：2011/12/10(土) 22:51:43.27

msysgitのutf-8対応
http://code.google.com/p/msysgit/issues/detail?id=80
http://groups.google.com/group/msysgit/browse_thread/thread/40112decdc564117
インストーラ
http://groups.google.com/group/msysgit/msg/b2b53e1092e37440

766 ：デフォルトの名無しさん：2011/12/10(土) 22:52:59.45

>>763
ねえ、また >>705 からループするの？

767 ：デフォルトの名無しさん：2011/12/10(土) 22:55:59.77

ループするたびに底辺とバカにされるsvn使い可哀想

768 ：デフォルトの名無しさん：2011/12/10(土) 23:06:57.60

ほらほら >>758 からループしてるし。(w

769 ：デフォルトの名無しさん：2011/12/11(日) 01:07:24.34

>>765
Git-1.7.7.1-unicode-20111202
Git-1.7.8-preview20111206

上の二つ試してみたけど、特に改善しているように思えないなぁ

git config core.quotepath false

しても文字化け状態で表示される

windowsの場合コンソールがSJIS使うようになっているから
そっちも設定をいじる必要がありそう

770 ：769：2011/12/11(日) 01:34:55.76

コマンドプロンプトからはフォントをMSゴシックに変えて
chcp 65001したら日本語ファイル名いけるようになった。

bashのほうからも同じことをやったがこっちは
フォントが強制的に日本語含まれないフォントに変更されて
使えないようだ

771 ：デフォルトの名無しさん：2011/12/11(日) 15:42:52.69

gitで秒単位とかでファイルの変更箇所のログを取ることはできますか？

772 ：デフォルトの名無しさん：2011/12/11(日) 20:30:02.46

>>771
gitはそういうツールじゃない。
というかその手段自体があまりよろしくないように見える。
それでもやるならスクリプトでどうぞ。

773 ：デフォルトの名無しさん：2011/12/12(月) 07:36:02.56

ファイル改竄検知ソフトウェアあたりの仕事な気がする

774 ：デフォルトの名無しさん：2011/12/12(月) 17:29:09.20

git initすると.gitがつくられますが、
これを別の場所に置くことは出来るのでしょうか？

775 ：デフォルトの名無しさん：2011/12/12(月) 17:34:31.52

>>774
--separate-git-dir=<git dir>

776 ：デフォルトの名無しさん：2011/12/12(月) 17:49:37.41

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

777 ：デフォルトの名無しさん：2011/12/12(月) 19:17:26.32

Git、Eclipse.orgでCVS、SVNを超える
http://www.infoq.com/jp/news/2011/12/eclipse-git

778 ：デフォルトの名無しさん：2011/12/12(月) 19:41:23.29

>>777
後半のhgの所は間違っている。
bitbucketはプライベートリポジトリとして使われているケースが多い。
公開リポジトリが１つもないアカウントはいっぱいある。
hgのossプロジェクトは自前でリポジトリを立てている所が多い。
http://mercurial.selenic.com/wiki/ProjectsUsingMercurial

779 ：デフォルトの名無しさん：2011/12/12(月) 20:50:53.14

はいはい

780 ：778：2011/12/12(月) 21:09:57.78

Gitスレに誤爆してしまった。
bitbucketは、個人も5人までのチームも、無料でプライベートリポジトリも含めて容量制限無しなんで、
ぜひ使ってくださいね♡
>777はsvnスレに張らなくて良いのかね？

781 ：デフォルトの名無しさん：2011/12/12(月) 21:59:23.02

Mercurialに続きGitもUnicode対応になるのか。胸熱だな...

あとはrename問題が解決すればGitで何の不自由も無くなるのに

782 ：デフォルトの名無しさん：2011/12/12(月) 22:59:02.13

>>771
ひょっとして git blame とかかな？
コミット単位だけど秒も出ているといえば出ている。

783 ：デフォルトの名無しさん：2011/12/13(火) 00:49:35.25

GITは自分一人が使う分には全く問題ないが、この複雑なコマンド体系を
チームメンバー全員が使いこなせるとは到底おもえないのがネックなんだよな・・

HGはそのへんSVNライクだし、SVNユーザーが移行する分には生涯なさそうだが
正直Hg使うくらいならSVNで十分だろって議論もあるしブツブツ・・

784 ：デフォルトの名無しさん：2011/12/13(火) 01:07:48.69

>>783
> 正直Hg使うくらいならSVNで十分だろって議論
さすがにそれはない

785 ：デフォルトの名無しさん：2011/12/13(火) 14:23:32.42

よく使うコマンドってなんですか？

git init
git add
git commit
git clone
しか知らないんですが、全てを覚えるのはきついので最低限覚えておくべきコマンドを教えてください

786 ：デフォルトの名無しさん：2011/12/13(火) 14:24:55.82

その4つで困ってないならお前にとって必要なコマンドはその4つだろ

787 ：デフォルトの名無しさん：2011/12/13(火) 15:34:51.30

お前がそう思うならそうなんだろう
お前ん中ではな

788 ：785：2011/12/13(火) 15:40:43.34

>>786
仲間か
一緒に勉強してこうぜ

789 ：デフォルトの名無しさん：2011/12/13(火) 15:42:18.00

こうしてclone厨が生まれるのであった

790 ：デフォルトの名無しさん：2011/12/13(火) 15:46:07.79

git status
git branch
git checkout
git merge
git mergetool
git pull
git push

これらと>>785のコマンド以外を使うときはマニュアル見てしまう

791 ：デフォルトの名無しさん：2011/12/13(火) 20:52:02.85

rebase -iを堪能しないとgitの意味がない(個人の見解です)

792 ：デフォルトの名無しさん：2011/12/13(火) 20:53:52.11

俺的にはadd -pだな

793 ：デフォルトの名無しさん：2011/12/13(火) 21:22:57.47

git reset なしで生きられない俺は間違った使い方をしているのだろう

794 ：デフォルトの名無しさん：2011/12/13(火) 21:27:26.05

1日に何度もgit pullしちゃう

795 ：デフォルトの名無しさん：2011/12/13(火) 21:30:18.30

最近pullよりfetch && rebaseだなー

796 ：デフォルトの名無しさん：2011/12/13(火) 21:38:35.68

add
↓
commit
の流れでバックアップして、最新のバックアップが欲しいときにcloneしてるけど
このやり方で合ってますか？

797 ：デフォルトの名無しさん：2011/12/13(火) 21:49:14.44

こうしてclone厨が生まれたのであった

798 ：デフォルトの名無しさん：2011/12/13(火) 23:26:41.52

リポジトリの複製が欲しいならcloneでいいが、
ある時点のスナップショットのアーカイブが欲しいだけなら git archive

799 ：デフォルトの名無しさん：2011/12/13(火) 23:29:25.02

リポジトリをgithubからbitbucketに移行したいんだけど、やり方が分からない。
.git/config を書き換えるだけでいいのかなあ。
だれか教えて。

800 ：デフォルトの名無しさん：2011/12/14(水) 03:07:36.93

>>795
git-pull --rebase じゃダメな領域? tracking branch じゃなかったらたしかに rebase は別途やるな、俺も。

俺ブームは detached branch での作業あんど detached branch(要はsha1)に対する rebase.

801 ：デフォルトの名無しさん：2011/12/14(水) 08:55:10.72

最近は git pull より git pull --reabese 使おうぜってのをよく見かける

802 ：デフォルトの名無しさん：2011/12/14(水) 12:01:58.71

>>799
remote追加してpushするだけじゃないの？

803 ：デフォルトの名無しさん：2011/12/14(水) 19:51:50.00

困ったときのgit bisectとか
毎日使うgit log --all --graph --decorateとか
git grepも無いと困る。

804 ：デフォルトの名無しさん：2011/12/15(木) 07:21:20.31

gitでlogを見た時に、どのブランチに対するコミットなのかを調べるには
どうすればいいんですかね？

具体的には、GitXでBranchをAll branchesにしてコミットを発見したんだけど
そのコミットがどのブランチに対するコミットかわからない状態です。

SHAはわかっているのでログは見られるけど
ブランチが多すぎてどれに対するコミットかわからないんです。

コマンド名や検索ワードだけでも教えてもらえると助かります。

805 ：デフォルトの名無しさん：2011/12/15(木) 07:41:30.61

>>804
何故ブランチが多いのだ？
マージが終わったらブランチは消そう。

806 ：デフォルトの名無しさん：2011/12/15(木) 17:37:07.01

>>804
一個上のレスにある
git log --all --graph --decorate
じゃダメなん？

807 ：デフォルトの名無しさん：2011/12/15(木) 19:18:42.32

gitx使ってるっていうんだから、どのブランチに繋がっているかは分かってるんでしょ？
きっと問題は繋がっているブランチがマージコミットを通して複数あって、そのどのブランチで作業しているときにコミットしたもんだか分からないってことだと思う。
マージコミットの一つ目の親の方向から辿れば分かると思う。

808 ：デフォルトの名無しさん：2011/12/15(木) 19:38:36.44

わからないです

809 ：デフォルトの名無しさん：2011/12/16(金) 19:04:52.90

TortoiseGit1.7.6.0

810 ：デフォルトの名無しさん：2011/12/17(土) 16:48:06.75

RHEL6.1入れたらgitがすでにインストールされていた

811 ：デフォルトの名無しさん：2011/12/19(月) 11:07:25.67

git rebase -i head^ で出てきた一行だけを、くっつくかなと
思って squash に変更したらコミットが消えたし…
reflog で救出したけど

812 ：デフォルトの名無しさん：2011/12/19(月) 22:09:56.96

未コミットの変更を git reset --hard で消してしまった場合って救出不可能？

813 ：デフォルトの名無しさん：2011/12/19(月) 22:34:03.62

git歴1日の俺がちょうど今調べてたのがgit reflogだ

814 ：デフォルトの名無しさん：2011/12/19(月) 22:34:49.17

cd c:\test\code\
git init
git add .
git commit -m "testdesu"
までやりました
そしてためしにc:\test\code\内のファイルを部消しました（.gitは残してます）
ここからなんですが
どうやってgitからファイルを取得するのでしょうか？

815 ：デフォルトの名無しさん：2011/12/19(月) 23:13:51.69

git checkout .

816 ：デフォルトの名無しさん：2011/12/19(月) 23:46:15.28

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

817 ：デフォルトの名無しさん：2011/12/20(火) 00:02:39.59

>>812
addしてたファイルはlost-foundで救出できる

818 ：デフォルトの名無しさん：2011/12/20(火) 22:46:10.16

gitってテキストファイル以外にもexeファイルや画像などのバイナリファイルも保存できるのですか？
壊れたりしませんか？

819 ：デフォルトの名無しさん：2011/12/20(火) 23:01:29.78

>>818
できます
しません

820 ：デフォルトの名無しさん：2011/12/20(火) 23:16:26.85

>>818
http://progit.org/book/ja/ch7-2.html
マージはできんけど、コマンドかましてファイル情報のdiff取る事はできる。

821 ：デフォルトの名無しさん：2011/12/21(水) 08:05:15.71

>>817
なるほど、ありがとう
未addはさすがに無理か…

822 ：デフォルトの名無しさん：2011/12/22(木) 19:37:46.95

訳あって work tree を全部削除したので clone し直したのですが、
git remote add って手動でやり直さないとダメなんでしょうか？

823 ：デフォルトの名無しさん：2011/12/22(木) 20:48:39.71

>>822
.git/ を消してないならcloneし直さなくてもcheckoutで復旧しますよ

824 ：【東電 81.2 %】：2011/12/28(水) 22:11:22.83

git コミット ID の衝突確率
http://d.hatena.ne.jp/nurse/20111228
> 結論: git はまぬけ

825 ：デフォルトの名無しさん：2011/12/28(水) 23:19:18.38

先頭の7文字だか10文字だかしか保存してないとでも思ってるのか?

826 ：デフォルトの名無しさん：2011/12/29(木) 01:54:36.11

ブロガーを信用するってまぬけだな

827 ：デフォルトの名無しさん：2011/12/29(木) 03:01:48.73

自慢気にrubyコミッタて書いてるわ…

828 ：デフォルトの名無しさん：2011/12/29(木) 04:04:15.13

>>824
SHA-1ハッシュのリスクもメリットも一切理解出来てないんだな。
痛いなあ…単にアーアー聞こえないなのかも知れないが。

829 ：デフォルトの名無しさん：2011/12/29(木) 08:03:39.41

>>824-828
「id:nurseはGitの内部でSHA-1ハッシュの先頭数文字しか使っていないと勘違いしている」
とでも勘違いしてるのか？

830 ：デフォルトの名無しさん：2011/12/29(木) 08:23:29.40

うむ、読めばそういう話じゃないことはわかるのに、何ファビョってんだかｗ

831 ：デフォルトの名無しさん：2011/12/29(木) 08:29:40.36

無限ハッシュ値地獄で悶えて市ね

832 ：デフォルトの名無しさん：2011/12/29(木) 14:03:16.70

>>829
じゃ何の問題も無いのに何でGit全然ダメになるんだ？

833 ：デフォルトの名無しさん：2011/12/29(木) 15:03:55.20

るｂｙｓｔはぎｔとｐｙてょｎが嫌い

834 ：デフォルトの名無しさん：2011/12/29(木) 15:07:26.46

>>833
日本語でおｋ
マジレスするとshyouheiのGithubレポジトリがあるしmatzはquilt使ってる

835 ：デフォルトの名無しさん：2011/12/29(木) 15:16:27.17

649 デフォルトの名無しさん [sage] 2011/12/29(木) 14:50:37.28 ID: Be:
学生プログラマ日本一決定戦(予選は社会人も参加可)
ttp://codevs.jp/howto.html
現在予選開催中
応募締切 2012.1.6　12:00

おもしろいことやっているじゃん。誰か今から参加しろよ。

836 ：デフォルトの名無しさん：2011/12/29(木) 21:28:45.34

Gitの衝突確率とかPro Gitにすでに書いてあるっつーのに
http://progit.org/book/ja/ch6-1.html

それよりも「あなたの所属する開発チームの全メンバーが、同じ夜にそれぞれまったく無関係の事件で全員オオカミに殺されてしまう」可能性のほうがよっぽど高いことでしょう。

837 ：デフォルトの名無しさん：2011/12/29(木) 22:26:54.38

オオカミは絶滅した。そういうことになってる

838 ：デフォルトの名無しさん：2011/12/29(木) 22:38:00.48

それニホンオオカミ

839 ：デフォルトの名無しさん：2011/12/29(木) 23:33:23.28

>>836
お前はなんでそんなとんちんかんなことをドヤ顔で語ってるんだ？

840 ：デフォルトの名無しさん：2011/12/30(金) 00:36:24.18

gitはまぬけって結論がなあ

841 ：デフォルトの名無しさん：2011/12/30(金) 06:17:03.77

結論: git はうんこ

842 ：デフォルトの名無しさん：2011/12/30(金) 07:24:44.69

>>839
よく読めば引用だとわかる

なんか計算の問題（の解釈）のような気がする

843 ：デフォルトの名無しさん：2011/12/30(金) 08:45:10.78

>>840
間抜けだろう。
元々linuxカーネルのソースコード管理目的で作られてるのに、
本来の目的の使用であまり良いとは言えない局面が存在するんだから。

844 ：デフォルトの名無しさん：2011/12/30(金) 09:23:40.92

>>843
どういう局面で良くないの？

845 ：デフォルトの名無しさん：2011/12/30(金) 09:46:02.06

>>844
佐藤がクラスに５人いるのに名字で呼んだら誰だか分からない。

846 ：デフォルトの名無しさん：2011/12/30(金) 09:56:22.19

フルネームとまではいかなくても名前（の一部）も付けて呼べばいいんや
あだ名（タグ）つけてしまうって手もなくはないぞ

847 ：デフォルトの名無しさん：2011/12/30(金) 10:24:15.06

>>844-845
そこは「同じクラスで誕生日が同じ人がいる可能性は高い」の方が良いかとｗ

848 ：デフォルトの名無しさん：2011/12/30(金) 10:26:24.60

>>847
デフォルトの表示の七桁が「まぬけ」なんだから名字でOK

849 ：デフォルトの名無しさん：2011/12/30(金) 11:54:08.01

デフォルト7桁って何のことを言ってんだ？
単に40文字を省略して途中まで表示してるだけだぞ？
それに省略表示されるのはほんとに表示領域が狭い時だけ。git logとかやってみろよ。
省略表示しかされないからどっちのオブジェクトだか分からないなんてことは、無い。

850 ：デフォルトの名無しさん：2011/12/30(金) 11:57:04.34

>>849
だから、メールの本文とか、デプロイツールとかで、どのリビジョンってのに、七桁だと衝突する可能性があるって話なんだから、
「佐藤」では短すぎるって例えなのに。

851 ：デフォルトの名無しさん：2011/12/30(金) 12:07:28.19

苗字だけじゃなくて名前も呼んでくれって話なの？

852 ：デフォルトの名無しさん：2011/12/30(金) 13:20:16.65

>>849
git log --oneline

853 ：デフォルトの名無しさん：2011/12/30(金) 14:08:11.63

>>850
デプロイツールって何のことか分からんけど
plumbingで7桁でやり取りするようなのは無いよ。

>>852
onelineの指定は一行で表示する為に自分で明示して
省略させてるだろ。意味分かってる？

七文字じゃ足りないのは初めから分かってたことで、
単に見やすさの為に省略してるだけなんだから、
linuxカーネルみたいな巨大プロジェクトは省略せずに
フルで表記。それだけの話だよ。

854 ：デフォルトの名無しさん：2011/12/30(金) 14:28:17.73

>>853
> デプロイツールって何のことか分からんけど
http://ftp.riken.jp/Linux/fedora/development/rawhide/source/SRPMS/
bios_extract-0-0.7.20101207gitd65284d.fc15.src.rpm
d65284d

855 ：デフォルトの名無しさん：2011/12/30(金) 14:31:05.76

>>853
> onelineの指定は一行で表示する為に自分で明示して
> 省略させてるだろ。意味分かってる？
git branch -v

856 ：デフォルトの名無しさん：2011/12/30(金) 16:07:27.63

ああ
ようするにファイルのタイムスタンプとかで
年を省略したらどうなるかって話か

857 ：デフォルトの名無しさん：2011/12/30(金) 16:10:01.90

>>855
branchはporcelainだろ。UIの為のコマンドであって、
ツールキットとして使うようなものじゃない。

>>854
ファイル名がどうかしたか？

858 ：デフォルトの名無しさん：2011/12/30(金) 16:40:16.68

> >>854
> ファイル名がどうかしたか？
http://pkgs.fedoraproject.org/gitweb/?p=bios_extract.git;a=blob;f=bios_extract.spec;h=d8df4384ced19bafbb99b1e147322be36c964f53;hb=HEAD#l1

859 ：デフォルトの名無しさん：2011/12/30(金) 16:47:02.94

>>857
git rev-parse --short HEAD

860 ：デフォルトの名無しさん：2011/12/30(金) 17:09:01.43

>>858
で？

>>859
わざわざ --short なんてオプション付けといて「省略されてんじゃねーか！」
って文句言うのか？w

861 ：デフォルトの名無しさん：2011/12/30(金) 17:10:19.10

馬鹿には無理

862 ：デフォルトの名無しさん：2011/12/30(金) 17:13:55.03

>>860
--short, --short=number
Instead of outputting the full SHA1 values of object names try to abbreviate them to a shorter
unique name. When no length is specified 7 is used. The minimum length is 4.

863 ：デフォルトの名無しさん：2011/12/30(金) 17:30:53.36

>>862
だから？
「SHA1を途中で省略して短く出してね」って自分で指示しておいて
「省略したらユニークにならなかった！Gitダメじゃん！」って頭おかしいだろ。

864 ：デフォルトの名無しさん：2011/12/30(金) 17:33:50.79

最近「頭悪い質問で釣ってみた」の投稿多いな。

865 ：デフォルトの名無しさん：2011/12/30(金) 17:34:23.99

>>863
When no length is specified 7 is used.

866 ：デフォルトの名無しさん：2011/12/30(金) 17:35:54.33

867 ：デフォルトの名無しさん：2011/12/30(金) 17:36:12.46

で？

868 ：デフォルトの名無しさん：2011/12/30(金) 17:37:05.85

知り合いがネット上ではネカマのふりをしてたほうが
アホな男が優しくしてくれるって言ってた。

869 ：デフォルトの名無しさん：2011/12/30(金) 17:47:49.39

>>865
デフォ7桁なのが問題だって言いたいのか？ 10桁なら良かった？
ハッシュの衝突は原理的にどうやったって起こりうるけど、
そこが理解できないんですか？

あとめんどくせーから引用だけのレスはスルーするわ。

870 ：デフォルトの名無しさん：2011/12/30(金) 17:53:40.00

ハッシュの衝突はどうやったって起こりうるけどデフォ7桁は問題です

871 ：デフォルトの名無しさん：2011/12/30(金) 17:58:03.07

1234abc
1234cde

の2つのコミットがあったときに、
1234
って指定した場合ってどんな感じで怒られるん？

872 ：デフォルトの名無しさん：2011/12/30(金) 19:10:12.16

ぎっとはうんこ＝７文字
gitのデフォルト７桁は運命だった

873 ：デフォルトの名無しさん：2011/12/30(金) 19:20:03.22

UbuntuでVimを愛し、Githubでソースを公開し、
気に入ったプロジェクトがあればPull Requestを送り、
Haskellを勉強し、Pythonのブログを書いていたとしても、
俺は依然として無職だし、WIndowsでメモ帳でPHPを書いていても仕事は貰える！！

874 ：デフォルトの名無しさん：2011/12/30(金) 19:32:47.96

>>873
Ubuntu->Bazaar
Vim->Mercurial
Haskell->(元)Darcs
Python->Mercurial
WIndows->VSS

あなたがgitを使う理由はありません

875 ：デフォルトの名無しさん：2011/12/30(金) 19:44:23.08

VSSそれはひょっとしてギャグで言っているのか？

876 ：デフォルトの名無しさん：2011/12/30(金) 21:52:19.40

gitは間抜けって言いたかっただけだろ
http://ja.m.wikipedia.org/wiki/Git

877 ：デフォルトの名無しさん：2011/12/30(金) 22:18:22.02

G党ハマ抜け

来季のセ・リーグのスローガン

878 ：デフォルトの名無しさん：2012/01/05(木) 23:12:16.91

Git を使って2週間です。バージョン管理システム的なものをさわるのは初めてです。
Subversion も使ったことがありません。

うちの会社では社員がサーバーを勝手にたてられず Git サーバを使えません。
Windows の共有フォルダならばRead/Writeで開放されているのですが、

　　"\\xyz.net\\課フォルダ\偶数\3242\"

という日本語混じりのウンコなパスが設定されています。xyz は会社名です。
ここに repos というディレクトリをつくって

　　"\\xyz.net\\課フォルダ\偶数\3242\repos\"

DOS窓からアクセスしてみました

　　c:\develop\prj > pushd "\\xyz.net\課フォルダ\偶数\3242\repos\"
　　z:\課フォルダ\偶数\3242\repos > git --bare init
　　z:\課フォルダ\偶数\3242\repos > popd
　　c:\develop\prj > git push "\\xyz.net\課フォルダ\偶数\3242\repos\" master

2行目で、共有フォルダにベアなリポジトリを作成することは成功したのですが、
4行目で、fatal: does not appear to be a git repository で失敗してしまいます。

日本語混じりのパスをうまく切り抜ける方法はございませんでしょうか？

879 ：デフォルトの名無しさん：2012/01/05(木) 23:32:00.14

c:\develop\prj > net use z: "\\xyz.net\課フォルダ\偶数\3242"
c:\develop\prj > git push z:\repos master

880 ：デフォルトの名無しさん：2012/01/05(木) 23:52:14.32

>>879 さん
あした会社でためしてみます。ありがとうございました。

881 ：デフォルトの名無しさん：2012/01/06(金) 00:28:18.20

git cat-file tree 1234567 > hoge
git add hoge
としてもハッシュ値が衝突しないのはなんで？

882 ：881：2012/01/06(金) 00:46:48.48

先頭にオブジェクトの種類とサイズがつくからか

ttp://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html
ttp://alblue.bandlem.com/2011/08/git-tip-of-week-trees.html
ttp://alblue.bandlem.com/2011/09/git-tip-of-week-commits.html

883 ：878：2012/01/07(土) 10:03:22.79

会社でためしました。
ウインドウズの共有フォルダで Git 使うのうまくいきました、ありがとうございました。

884 ：デフォルトの名無しさん：2012/01/07(土) 10:24:25.88

すみませんが、質問です。

私は、Linux上のGitでSJISのソースコードを扱っているのですが、
コミットコメントなどはUTF-8になっているようです。

環境はja_JP.UTF-8なので、
コミットコメントなどは文字化けせず、ソースコードのdiffが
文字化けします。

どちらも文字化けしないようにする設定はないでしょうか？

なお、こんなページを見つけたので、
http://www.greenwood.co.jp/~k-aki/diary/diary201004.xhtml#d20100424
このgit-encwrapper というソフトを試してみましたが、
Linux, Cygwinどちらの環境でもビルドに失敗しました…。

885 ：デフォルトの名無しさん：2012/01/07(土) 10:25:15.92

もう一つ、今度はgit cloneについての質問です。

git clone を実行するとき、出力先ディレクトリが空でないと失敗します。
これで失敗せず、既存のファイルを残す設定はないでしょうか？
svn checkout --force のような。

以上です。よろしくおねがいします。

886 ：デフォルトの名無しさん：2012/01/07(土) 10:34:09.31

>>884

ページャを 'lv -c' にでもすればとりあえずは解決しそうだけどそれじゃ駄目かな？

887 ：884：2012/01/07(土) 10:48:31.28

>>886

なるほど、このやり方で、単体で起動した場合はうまく行きました。
ありがとうございました。

後出しですみませんが、実は私は、普段はmagitというEmacsの
Gitフロントエンドを使っておりまして、これはlogとdiffを
混在して出力しますので、
diffだけをUTF-8に変換する必要があるのです。

It's Magit!
http://philjackson.github.com/magit/

888 ：884：2012/01/07(土) 10:52:20.13

同じ事で悩んでいた、git-encwrapperの作者の方の日記を、
参考のために貼ります。

2010年04月の日記
http://www.greenwood.co.jp/~k-aki/diary/diary201004.xhtml

2010年04月24日(土) あたりが、それについて書かれたものです。

889 ：デフォルトの名無しさん：2012/01/07(土) 12:28:09.64

>>54
できるようになるらしい
Git v1.7.9 Release Notes (draft)
ttp://article.gmane.org/gmane.comp.version-control.git/188049
* "git branch --edit-description" can be used to add descriptive text
to explain what a topic branch is about.

890 ：デフォルトの名無しさん：2012/01/07(土) 14:25:04.31

はじめてのGit導入で初コミット
git add .
git commit -m "a"
～　数日後ファイルの更新～
git add .
git commit -m "b"
～　数日後ファイルの更新～
git add .
git commit -m "c"
～　数日後ファイルの更新～
git add .
git commit -m "d"
ここでcomitt "b"のときのデータを取得したい場合はどのように取得するのでしょうか？

891 ：デフォルトの名無しさん：2012/01/07(土) 14:45:10.82

>>890
git checkout HEAD^^

892 ：デフォルトの名無しさん：2012/01/07(土) 15:27:16.00

>>891
ありがとうございます
git checout HEAD＾＾をやって2つ前のに戻した場合、cとｄのは消えちゃうのでしょうか？

893 ：デフォルトの名無しさん：2012/01/07(土) 17:30:21.27

>>892
NO
checkoutでは履歴は変化しないだろ

resetしてブランチを古いコミットに移動したら消えたように見えるけど
reflogを使ってハッシュを見れば復元できる

resetした後gcしたら古いコミット消えるかもしれないけどわけんね

894 ：デフォルトの名無しさん：2012/01/07(土) 17:33:06.98

reflog地獄で悶えて氏ね

895 ：893：2012/01/07(土) 17:35:43.92

到達できなくなったコミットはgcすると、
デフォルトで2週間前以上のは消えるみたい

--prune=<date>
Prune loose objects older than date (default is 2 weeks ago, overridable by the config variable gc.pruneExpire). This option is on by default.

896 ：デフォルトの名無しさん：2012/01/07(土) 17:42:57.90

>>894
地獄言いたいだけちゃうんかと・・・。

897 ：デフォルトの名無しさん：2012/01/07(土) 18:15:09.00

地獄言いたいだけちゃうんかと・・・。

898 ：デフォルトの名無しさん：2012/01/07(土) 18:40:43.94

そんなに大事なことだったかね。

899 ：デフォルトの名無しさん：2012/01/07(土) 18:43:01.95

reflog hellで悶えて氏ね

900 ：デフォルトの名無しさん：2012/01/08(日) 08:48:54.20

リフログってカタカナで書くと魔法っぽい

901 ：デフォルトの名無しさん：2012/01/08(日) 08:54:10.17

りふろぐってひらがなで書くとうんたんっぽい

902 ：デフォルトの名無しさん：2012/01/08(日) 09:39:46.10

githubにあげるとニートがばれるので
非公開で無料でgitできるオンラインサービスありませんか？

903 ：デフォルトの名無しさん：2012/01/08(日) 09:51:12.66

>>902
bitbucket

904 ：デフォルトの名無しさん：2012/01/08(日) 10:04:20.98

非公開できないじゃん＞＜

905 ：デフォルトの名無しさん：2012/01/08(日) 10:06:55.52

private っていう単語の意味分かる?

906 ：デフォルトの名無しさん：2012/01/08(日) 10:08:56.67

>>904
https://bitbucket.org/
> Unlimited DVCS Code Hosting, Free
> Store all of your Git and Mercurial source code in one place with unlimited private repositories. Includes issue tracking, wiki, and pull requests

*private*

907 ：デフォルトの名無しさん：2012/01/08(日) 11:02:46.06

ニートで無教養か…頑張れよ

908 ：デフォルトの名無しさん：2012/01/09(月) 00:52:55.50

ついにニートもgitを操る時代か
胸熱

909 ：デフォルトの名無しさん：2012/01/09(月) 03:26:28.91

この流れでふと思ったんだが、
次スレのテンプレに↓くらいはあったほうがいいのかね。

◆git repository hosting services
github
http://github.com/
Bitbucket
https://bitbucket.org/
Gitorious
https://gitorious.org/
Google Code
https://code.google.com/

Comparison of open source software hosting facilities
https://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

910 ：デフォルトの名無しさん：2012/01/09(月) 12:39:24.43

無料版で非公開に出来るサービスはBitbucketだけ？

911 ：デフォルトの名無しさん：2012/01/10(火) 17:59:25.23

無料じゃうっかりミスで公開されても文句言えねえから使う気せんがな

912 ：デフォルトの名無しさん：2012/01/10(火) 18:00:48.58

>>911
Githubなら有料で非公開にできるぞ
やったね！

913 ：デフォルトの名無しさん：2012/01/10(火) 19:16:28.33

Bitbucketってクソだな
無料版は5個しかリポジトリ作れないのかよ

914 ：デフォルトの名無しさん：2012/01/10(火) 19:21:53.29

>>913
つ906
*unlimited*

915 ：デフォルトの名無しさん：2012/01/10(火) 19:29:55.49

ニートで無教養地獄で悶えて氏ね

916 ：デフォルトの名無しさん：2012/01/10(火) 19:35:08.51

"Sign up for a free 5 user account(五人までの面子で使える無料1アカウント)"
を読んで早合点したと思われる。

917 ：デフォルトの名無しさん：2012/01/15(日) 11:23:54.25

Bitbucketって一定日数利用しなかったらデータ削除とかありますか？
Dropboxは3ヶ月

918 ：デフォルトの名無しさん：2012/01/16(月) 12:38:40.71

git commit --amend しても直前の「間違ってた恥ずかしい」コミットは内部に残るのね…

919 ：デフォルトの名無しさん：2012/01/16(月) 13:01:17.86

>>918
残ってて良かった例

$ edit neko.dat
$ git commit -m 'ねこかわいいにゃん'

# 上矢印キーでシェルヒストリ呼び出し
$ git commit -m 'ねこっていうかトラだった' --amend

# 上矢印キーでシェルヒストリ呼び出し
$ git commit -m 'てかメスのライオンだった' --amend

$ edit inu.dat
# 上矢印キーでシェルヒストリ呼び出し
$ git commit -m 'いぬかわいいわん' --amend

Σ(ﾟДﾟ|||) amendﾂｲﾃﾀ!!

$ git reset HEAD@{1}
$ git commit -m 'いぬかわいいわん'

920 ：デフォルトの名無しさん：2012/01/16(月) 13:01:21.61

>>918
しばらくすればpruneできる
でも「しばらくする」前にpruneするにはどうすればいいんだろう

921 ：デフォルトの名無しさん：2012/01/16(月) 19:43:43.79

prune のオプションで時間指定できるだろ

922 ：デフォルトの名無しさん：2012/01/17(火) 00:51:31.67

>>919
分かりやすい！こういうの好きだわｗ
そのノリで他にもなんかタノムｗ

923 ：デフォルトの名無しさん：2012/01/17(火) 03:46:56.60

>>919
あるある

924 ：デフォルトの名無しさん：2012/01/17(火) 08:26:39.41

919についてもう少し詳しく知りたいんですが、
何をキーワードに検索してみれば良いでしょうか?

925 ：デフォルトの名無しさん：2012/01/17(火) 09:56:28.13

>>924
reflog

926 ：デフォルトの名無しさん：2012/01/17(火) 19:34:44.45

どうもです。
帰ったら調べてみます。

927 ：デフォルトの名無しさん：2012/01/17(火) 20:31:49.67

gitを使う前にgitkを起動してけばHEAD@{1}なんて文法を知らなくてもいいので便利

928 ：デフォルトの名無しさん：2012/01/17(火) 20:34:46.61

mオプション怖いからいつもviでコミットログ書いてる。
怖いというか、書き損じが恥ずかしいというか。
スペルチェッカ通さないと、いらん恥かきそうで。

929 ：デフォルトの名無しさん：2012/01/18(水) 02:31:39.70

git clone --mirror した場合。

A -> B -> C

といった感じで A から B に mirror して C で作業。
C に commit して B に push。そして B から A に push した時に、
別の人が A に push した後だとログも何も出ずに push が
出来ていない状態になってしまいます。
どこまで A に push 出来たかよく判らなくなるんだけど

mirror は読み取り専用を想定していて push は直接 A にしてね。
っていうのが正しい使い方なのかな？

930 ：デフォルトの名無しさん：2012/01/18(水) 10:48:04.95

そもそも push は fast forward しかできないから A に他の人の commit があるなら
先に B (か C) で A の commit を取り込んだ merge commit を作ってから push しないと
いけないんじゃないかな

931 ：デフォルトの名無しさん：2012/01/18(水) 11:09:52.87

>>930
そう、その通りです。
なので B で fetch して C で pull すれば良いのですが、
B で push 出来なかった時にエラー表示も何も出ないので
fetch pull が必要どうかが判らないんですよ。

932 ：デフォルトの名無しさん：2012/01/18(水) 20:57:54.26

しつもん

git でブランチ間を移動するとき、実際のファイルシステム上では rm や cat > や cp 相当のファイル書き込みが連打してたりしますか？
git checkout branch とするとき、100個のファイルが「現れる」ならば、ファイルシステム上では100個のファイルが作成されていますか？

HDD への書き込みが頻繁になるのがやだなあと思うので、git で開発するディレクトリをいわゆる RAM ドライブにしようかと思ってるんですが

933 ：デフォルトの名無しさん：2012/01/18(水) 23:00:07.78

>>932
その通りなんで、必要だと思うことをすればいい。

934 ：デフォルトの名無しさん：2012/01/18(水) 23:02:17.67

>>932
.git/以下はほとんど書き込みはないが、それ以外は変更されるファイルはまる
まる書き換えられるよ。気になるなら.git/以下だけHDDとかにすれば。

935 ：デフォルトの名無しさん：2012/01/19(木) 00:15:41.92

>>932
よく考えりゃ当たり前なんだが、そうするとあんまり気持ちのいいものではないな…
メモリが余ったら俺も考えよう…

936 ：デフォルトの名無しさん：2012/01/19(木) 08:03:38.16

Gitblit ってどうなの？
イントラで使う場合に Gitorious から乗り換える価値ある？

937 ：デフォルトの名無しさん：2012/01/19(木) 14:12:04.64

>>932
linux kernelでブランチをまたがって開発してるとかなら、
たしかにRAMディスク使いたくなるだろうけど、
ファイル数の増減が100くらいなら、気にしなくてもいんじゃね。

938 ：デフォルトの名無しさん：2012/01/19(木) 14:33:24.63

起動時と終了時（と定期的）にHDD内容と同期させることができ（て不意の電源断に泣かない根性があ）るのなら、
gitで管理する開発ディレクトリをRAMディスクに展開するデメリットは特にないと思う
もちろん活発にコード書かないとご利益は薄いけど…

939 ：デフォルトの名無しさん：2012/01/21(土) 15:03:15.89

>>936
君んとこで評価して結果を晒してくれたら
喜ぶ人がけっこういるんじゃないかな。

940 ：デフォルトの名無しさん：2012/01/24(火) 00:10:21.68

bitbucketを使ってgitで設定ファイルをdotfilesというリポジトリで管理したいんです。
で、マシンごとに微妙に設定が違うので、たとえばフォントの大きさが違うとか、
そういうのを管理するにはフォークとかブランチとかが使えそうなのかなと思ったんです。
そこで、マシンごとの設定ファイルをいじっててこの設定はどのマシンでも使いたいとなった場合、
どういう風にすると楽に管理できますか？

941 ：デフォルトの名無しさん：2012/01/24(火) 01:40:14.85

これとbitbucket組み合わせれば、望みの状況に近いんじゃないかな。
https://github.com/RichiH/vcsh/
debianならpkgもある。
http://packages.debian.org/source/sid/vcsh

942 ：デフォルトの名無しさん：2012/01/24(火) 02:21:02.21

>>941
紹介ありがとう。

>>1の入門のマニュアルを見ながらブランチとマージを試してみたら、
意外と手軽に扱えることが分かったので、
ブランチとマージで行ってみようと思います。

マシンごとの各ブランチに、
共通設定であるmasterをマージして回ることになりそうだけど、
１つのワーキングコピーでできそうなので、まあいいかな。

943 ：デフォルトの名無しさん：2012/01/24(火) 11:13:49.27

初心者がgithubでコードを公開するときに使えておきたいコマンドの一覧を教えてください

944 ：デフォルトの名無しさん：2012/01/24(火) 11:34:33.50

コマンドというか、公開ブランチを綺麗にしておくこととコミットログをきちんと書くことが最重要
それができればなんでもいい

…だから、とりあえずgithubで公開してから考えるというのは全くお勧めしない
ローカルで間違えまくって修正の経験を積んだあと、満を持しての公開がベター

945 ：デフォルトの名無しさん：2012/01/24(火) 12:09:34.81

>>944
先生、ご指導ありがとうございます
綺麗にするというのはちゃんと動くコードのバージョンごとにコミットする事、よくわからないような改変のコードはコミットしない。これがきれいという認識でよいでしょうか？
コミットログは何を書いておけば嫌われなくなりますか？

946 ：デフォルトの名無しさん：2012/01/24(火) 13:32:04.68

bitbucketのRepository detailsに
No public forksっていうチェックボタンがありますがこれはなんですか？

947 ：デフォルトの名無しさん：2012/01/24(火) 14:15:57.79

公開ブランチの育て方というのはどっかにページなかったっけ

948 ：デフォルトの名無しさん：2012/01/24(火) 14:18:22.93

bitbucketでGitやりたいんですが
日本語マニュアルってないですか？
まとめwikiみたいなのお願いできませんか

949 ：デフォルトの名無しさん：2012/01/24(火) 14:32:08.49

ここから先は有料です

950 ：デフォルトの名無しさん：2012/01/24(火) 14:40:43.74

どうかたすけてください
git add .
git commit -m "commit1"
ってやったあとファイルを編集してさらに
git add .
git commit -m "commit2"
でリビジョンが2つある状態になりました
そこで
git checkout HEAD＾
で一つ前のリビジョン(commit1)に戻して
git checkout .
ってやって編集前のファイルを取得しました
そこで2つ目のリビジョンに戻りたいのですが
git logを見るとリビジョンが一つしかありません
消したらやばいコードがあるのでたすけてください

951 ：デフォルトの名無しさん：2012/01/24(火) 15:53:00.06

git checkout master

952 ：デフォルトの名無しさん：2012/01/24(火) 16:07:39.41

>>951
仏様ありがとうございます

953 ：デフォルトの名無しさん：2012/01/24(火) 16:13:48.24

消したらまずいコードの管理に使い方のわからないツールを使うところからまず見直したら。

954 ：デフォルトの名無しさん：2012/01/24(火) 16:52:43.63

uruse-ks

955 ：デフォルトの名無しさん：2012/01/24(火) 16:54:58.67

消したらまずいコードの管理に使い方のわからないツールを使う地獄で悶えて市ね

956 ：デフォルトの名無しさん：2012/01/24(火) 21:09:11.08

プレスリリースに「オープンソースとして公開」と書いてあるわけですから、オープンソースとして公開してください。
https://github.com/DeNADev/Arctic.js/pull/6

957 ：デフォルトの名無しさん：2012/01/24(火) 21:14:28.72

>>956
これはヒドイ
公開しといてこれはないだろ

958 ：デフォルトの名無しさん：2012/01/24(火) 21:18:17.93

>>956
MIT Licenceって公開されてるじゃん
読めないの？

959 ：デフォルトの名無しさん：2012/01/24(火) 21:23:28.92

https://github.com/DeNADev/Arctic.js/commit/b92eea0a83b9b01c53eb3f6fb65fdb8af6bc0aab

10分前に変更されたんだろ
スレ違いだが

960 ：デフォルトの名無しさん：2012/01/24(火) 21:24:25.35

あ、いま訂正されたみたい
英語だけどつまりどういうこと？
教えてエロイひと

961 ：デフォルトの名無しさん：2012/01/25(水) 08:09:04.12

>>936
インストールは楽だったが、機能的には最小限のようなので既に環境あるなら
今のところ様子見でいいよ。

962 ：デフォルトの名無しさん：2012/02/02(木) 18:30:30.24

EGitってrebaseとかstashとかサボートしてないんですか？

963 ：忍法帖【Lv=40,xxxPT】：2012/02/04(土) 11:17:48.46

>>940
一本化して可能な限り条件分岐で済ませた方がメンテは楽だよ。
条件分岐ができない類の設定ファイルならどうにもならないけど。

964 ：デフォルトの名無しさん：2012/02/04(土) 13:29:37.15

条件分岐できる設定ファイルの方が少ないと思うけど。

.profile とかのスクリプトとかのことを言ってるのか？

965 ：デフォルトの名無しさん：2012/02/04(土) 15:06:47.50

普通そういうコード書く側のマシン固有の設定ファイルはコミットしなくない？

966 ：デフォルトの名無しさん：2012/02/04(土) 15:19:40.35

ケースバイケースだと思う。
管理する場合にブランチ使うのは、悪くない考えだと思う。

967 ：デフォルトの名無しさん：2012/02/04(土) 15:24:38.80

そうなのか、俺はテンプレートだけコミットしておいて、別マシンで編集したあと手元でignore指定してる

968 ：デフォルトの名無しさん：2012/02/04(土) 15:31:25.22

* local環境はmasterをbranchして作る。
* local固有のものはlocalにコミットを足していく。
* 全体で共用可能なものはmasterブランチにコミットし、localをrebaseする。
* 部分的に共用可能なトピックはmasterからブランチを作って、localに明示的にマージする。

ドットファイルじゃないけどこんな感じでやってる。

969 ：デフォルトの名無しさん：2012/02/04(土) 17:14:35.17

.vim をgitにしてるよ。んでmacとLinuxで微妙に設定変えたいのでbranchにしてる。
そんなに面倒ではないんだけど、submoduleはやっぱ使いにくいな。なかなか慣れない。

970 ：デフォルトの名無しさん：2012/02/04(土) 18:22:09.64

ドットファイルは分岐とか細工しない方が楽な気がしてる。
昔は凝りに凝って色々やってたけど、今は基本ホスト別だわ。

971 ：デフォルトの名無しさん：2012/02/04(土) 19:05:34.15

git管理するドットファイルはHOMEに置かないで、HOMEに置いたのからsourceするようにしてる
sourceできるのじゃないと使えないけど

972 ：デフォルトの名無しさん：2012/02/04(土) 19:13:47.42

HOMEにおかないのは同じだけど、
シンボリックリンク張ってる

973 ：デフォルトの名無しさん：2012/02/04(土) 19:14:29.06

シンボリックリンク地獄で悶えて氏ね

974 ：デフォルトの名無しさん：2012/02/04(土) 19:17:32.95

よほどのアホでもない限り、悶えることなんてないし。

975 ：デフォルトの名無しさん：2012/02/04(土) 23:40:07.25

>>969
俺の場合.vimrcはgitで管理してるけど、
.vimはneobundle.vimに任せてある。
githubにあるプラグインもhgなプラグインも扱えるし、
バージョン管理のないプラグインも使える。
ちと、スレ違いか。

976 ：969：2012/02/05(日) 03:51:52.70

>>975
お、そういうのあるんだね。俺は pathogen.vim 使ってる。
どっちかというと gitを生で操作するほうが好きなんだよね。

977 ：デフォルトの名無しさん：2012/02/11(土) 00:55:07.15

gitosis とか gitolite って OS のユーザとしては一人しか作成しないのに、SSH 公開鍵だけでユーザを識別するのってどうやってるの？
SSHって認証時の公開鍵の選択を他のプログラムからフックできたりする？
そこの仕組みがイマイチ釈然としなくて・・・詳しい人いたら教えてください。

978 ：デフォルトの名無しさん：2012/02/11(土) 10:36:56.51

>>977
authorized_keys で公開鍵に対応するユーザのコマンドが書いておく

979 ：デフォルトの名無しさん：2012/02/11(土) 13:05:51.40

>>978
おお！
ありがとうございます。

gitolite ユーザの ~/.ssh/authorized_keys を見たら、追加した全ユーザの公開鍵が書いてあり、
それぞれに「command="/usr/bin/gl-auth-command user1"」のように書いてありました。

authorized_keys　ってこんなことできるんですね。

980 ：デフォルトの名無しさん：2012/02/13(月) 23:10:37.96

入門記事を読んでると、commitとかchangesetとか単語が出てくるんですけど、
commitとchangesetって違うものなんでしょうか。
今まで同じものだと思ってたのですが、もし違うなら教えて下さい。

981 ：デフォルトの名無しさん：2012/02/13(月) 23:21:42.15

TortoiseGit-1.7.7.0

982 ：デフォルトの名無しさん：2012/02/14(火) 06:11:51.48

commitとかchangesetとか単語が出てくる地獄で悶えて詩ね

983 ：デフォルトの名無しさん：2012/02/14(火) 06:27:19.55

あーコミットや、あーチェンジセットや。
そがものは、我を惑わしたもうのは我が業たるゆえんなるか。
我今地獄に至りてこの答えを求めたもう。
いかなる御仁にお聞き申す。この答えやいかに。
願わくば啓示を示し給え。

984 ：デフォルトの名無しさん：2012/02/14(火) 08:21:11.53

まんこスレ保守

985 ：デフォルトの名無しさん：2012/02/14(火) 17:01:32.70

まんこまんこ

986 ：デフォルトの名無しさん：2012/02/14(火) 17:46:08.69

初めて使ったがStashめちゃ便利なんだな。
もっと先に試しておくべきだったわ

987 ：デフォルトの名無しさん：2012/02/14(火) 18:23:32.43

まんこまんこまんこ

988 ：デフォルトの名無しさん：2012/02/14(火) 18:34:59.20

msysgitの最近のコミットにapplied utf-8 patchesと書いてあったが
msysgit公式でunicode対応来たの？

989 ：デフォルトの名無しさん：2012/02/14(火) 19:35:57.77

まんこまんこまんこまんこ

990 ：デフォルトの名無しさん：2012/02/14(火) 20:20:06.84

だれも>>980に答えてくれない。。。というか、答えられないのか？

991 ：デフォルトの名無しさん：2012/02/14(火) 20:38:51.14

>>980
＞入門記事を読んでると、commitとかchangesetとか単語が出てくるんですけど、
＞commitとchangesetって違うものなんでしょうか。
＞今まで同じものだと思ってたのですが、もし違うなら教えて下さい。

別にみんな答えられないわけじゃないと思うが…
ちなみに違う。
commitは変更を記録する操作のことで、changesetは変更単位の概念。

992 ：デフォルトの名無しさん：2012/02/15(水) 00:03:18.03

まんこまんこまんこまんこまんこまんこまんこまんこ

993 ：デフォルトの名無しさん：2012/02/15(水) 00:07:12.66

コミットしたことでできたsnapshotとコミット関連のメタデータを合わせてgitでは「commitオブジェクト」と呼ぶ。
changesetはgitとして特別な意味は無い。一般的な意味。

"commit"ができあがったsnapshotを表すのに対して
"changeset" は一つ前のcommitとの差分に注目した呼び方。
でも結局同じようなものを指していることもある。
"revision"もいろんな使い方をされる。本当に正しくは文脈によるとしか言えないかな

994 ：デフォルトの名無しさん：2012/02/15(水) 00:46:22.27

次スレ
Git 4
http://toro.2ch.net/test/read.cgi/tech/1329234309/l

995 ：デフォルトの名無しさん：2012/02/15(水) 07:31:14.58

まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ

996 ：デフォルトの名無しさん：2012/02/15(水) 12:42:03.07

いつの間にかmsysgitのサブモジュールのURLgithubに変わっていた
submodule update成功しないのってこのせいだったのか

997 ：デフォルトの名無しさん：2012/02/15(水) 14:18:46.76

まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ

998 ：デフォルトの名無しさん：2012/02/15(水) 14:27:16.77

git log で、ファイルが作成された・削除されたことを表示するにはどうしたらいいですか。
たとえば、testディレクトリ中のファイルが、どのコミットで作成・削除されたかを知りたいばあい、どうしたらいいでしょうか。

999 ：デフォルトの名無しさん：2012/02/15(水) 15:31:40.15

まんこ