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/
5 :デフォルトの名無しさん2011/07/12(火) 18:34:06.53
まんこまんこです。夏中には何かパッチ送ってみます。
22 :デフォルトの名無しさん2011/07/19(火) 00:02:58.01
>>5
言っとくけど git.vger の Signed-off-by は実名限定だからな。
そのふざけたハンドルを2chで名乗ってるのが誰なのかバレるぜ。
25 :デフォルトの名無しさん2011/07/19(火) 12:12:20.37
>>22
2chで実名でカキコするワケねーだろ。
Junioに向かってまんこまんこを名乗るワケねーだろ。
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 なんて綴ってられんよな?
11 :デフォルトの名無しさん2011/07/13(水) 13:16:39.40
>>9
コミットログとチェンジログは役割が違う
チェンジログはまとめ広報に近い
「今回のバージョンの変更点はgitのコミットログ見てくださいね^^v」というのは現状極めて不親切だ

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

実際にいつ誰がツリーにコミットしてソース上の変更行がどこかなんてのはチェンジログには不要というか余分
13 :デフォルトの名無しさん2011/07/13(水) 14:26:15.90
>>11
思うのは勝手だが一般的な流儀とはかけ離れてるなｗ
15 :デフォルトの名無しさん2011/07/13(水) 14:46:55.71
>>11
> バージョンパッケージングごとにバージョン間の動作の変更点と注意が書かれているのがチェンジログだと思う
オレはそれはリリースノートだと思うなぁ
10 :デフォルトの名無しさん2011/07/13(水) 12:28:07.75
連投スマンが、 ChangeLog(.txt) のコンフリクトを解消するのって本質的な作業じゃないよな。
14 :デフォルトの名無しさん2011/07/13(水) 14:37:52.70
このへん、普段どんなプロジェクト追っ掛けてるかによってもけっこう違う気はする
ブランチと pull リクエストの散発的な日付のマージが連打してる git のコミットログから
前バージョンとの変更点を見つけるのは、ものによってはかなりめどい
ソース上どんな変更があったのかは自明だが、それが意味するのはナンデスカみたいな
16 :デフォルトの名無しさん2011/07/13(水) 14:50:31.40
なんというか、「ここで変数 i に10を代入」的な1行コミットログを書く人がいると、なんかとてもめんどくさくなる感じ
ひとつひとつのコミットがきちんと有機的に構成されて説明が充分であれば、コミットログだけでなんとかなるんじゃないかと

でも普通はそんなコミットなんてしないよね
めんどくさいし、整合性も取りづらいというかむしろ全く取れない
「update README」 ではなく、README に何を書いたかきちんとコミットログに書いてる？
「merge branch xxxx」ではなく、そのブランチのマージによってソフトウェアに何が起こるかきちんと説明書いてる？
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とまったく同じにはならんのだろう
23 :デフォルトの名無しさん2011/07/19(火) 02:05:05.44
よく知らないけど mq ってパッチ管理のはずだから
同じことをしたいのなら StGIT とか Guilt になるんじゃないかな
オレの感覚だと git でできるコミット整理ができないから
パッチ管理の mq でお茶を濁している感じ
何か意図するところがあってそういう設計にしているってことなのかもしれないけど
30 :デフォルトの名無しさん2011/07/19(火) 19:52:38.13
質問させてください。
windows7 32bitにturtoisGitをインストールしたあと
右クリックのgit cloneを押すと
git have not installed が出てしまいます。
これはどのようにすれば解決するか教えてください。
33 :デフォルトの名無しさん2011/07/19(火) 20:16:46.76
Git-1.7.6-preview20110708.exe
は入っているのですが、git have not installedが出ます。
エラーの原因がわかりません。アドバイスをお願いいたします。
39 :デフォルトの名無しさん2011/07/25(月) 20:45:28.08
Macな知り合いにTower勧めようとしたんだけど、これって有償なのか。
もしかしてAll in Oneなパッケージなわけじゃなくて、ただのフロントエンド？
41 :デフォルトの名無しさん2011/07/25(月) 21:42:24.81
いや、自分WINなんですけど、Macだと簡単に操作できるアプリあったよな…
という記憶から引っ張り出してきまして。
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 :462011/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/
53 :デフォルトの名無しさん2011/07/30(土) 15:38:41.67
Git GUIでファイルを右クリック→git historyで当該ファイルのみに絞った変更履歴が出せて便利なのですが、
これに相当する操作をコマンドラインのみで行えないでしょうか？
56 :デフォルトの名無しさん2011/07/31(日) 00:21:14.30
>>53
gitgui使わないから分かんないんだけど、普通に git log パス じゃダメなん？
58 :532011/07/31(日) 11:51:18.53
>>56
>>>53
>gitgui使わないから分かんないんだけど、普通に git log パス じゃダメなん？

変更履歴という書き方がわかりずらかったですね、すいません
当該ファイルのみのコミットログも見れるに越したことはないのですが、
一番見たいのは当該ファイルのみのリビジョン間のdiffなんです
60 :デフォルトの名無しさん2011/07/31(日) 16:43:03.52
>>58
git diff --help
61 :デフォルトの名無しさん2011/07/31(日) 17:16:37.48
>>58
git log -p パス
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とか他人から
見えるのは、変数名同様にちゃんと考えているのだろうか。
57 :デフォルトの名無しさん2011/07/31(日) 07:04:46.54
>>55
git merge --no-ff とやって、担当者名/hogehoge-feature がログに残ることを義務付けている宗派がある
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
コミットログをちゃんと書いてれば
ブランチのコメントとか言い出さないと思うんだが。。。
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としてはセーブされないのですよね？
これらのコマンドが何をやってるのかをわかりやすく教えていただけないでしょうか？
81 :デフォルトの名無しさん2011/08/14(日) 06:02:40.76
>>72
git commitといっても今の変更内容を全ていっぺんにコミットしたくない場合もある。
ある目的をもってコード書いてるときに別のちょっとしたバグを見つけて直してしまったり。
あとから問題が発生してこのコミットをとりやめなきゃならなくなったときに後者のバグも生き返ってしまう。
そんなときのために、まずgit addでコミット予定の変更を選択して個別にコミットするよう2段階の構成になってる。
詳しくはステージングでググれ。
良いコミットを。
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の一つ前のコミットを指すのですか？
それとも、分かれたブランチの元にあるコミットを指すのですか。
82 :デフォルトの名無しさん2011/08/14(日) 06:05:18.89
>>79
git log --all --graph
して見えるグラフのコミットとコミットの間の線が親子関係。
85 :デフォルトの名無しさん2011/08/15(月) 01:24:22.39
>>82
1つめの親、2つめの親、というのはどうやって決まるんでしょうか
80 :デフォルトの名無しさん2011/08/14(日) 05:23:04.50
GitHubに登録したのはいいけれど、インターフェイスが英語だ。
日本語表記にできるみたいなのでしたいのだがどうすればいいですか？
83 :デフォルトの名無しさん2011/08/14(日) 07:56:56.50
>>80
日本語UIはこないだ廃止になった。超がんがれ。
84 :デフォルトの名無しさん2011/08/14(日) 14:11:25.61
>>79
とりあえず>>1のProGitとGit入門読んだらどうか。

>>83
あれなんで廃止になったんだろうね。
最近はGit本家もその辺前向きに進んでるのに。
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
となるエラーは何が悪いのでしょうか？
91 :デフォルトの名無しさん2011/08/16(火) 20:18:03.34
>>87
^で複数行入力はcmd.exeの仕様。
""で囲めば行けるはず。
92 :デフォルトの名無しさん2011/08/16(火) 20:48:16.24
>>90本当だ。.bashrc消したらいけました。
>>90>>91
確かにコマンドプロンプトが解釈してました。
コマンドプロンプトはシングルクォートも通らなかったりして、使うのが鬱陶しいですね。
88 :デフォルトの名無しさん2011/08/16(火) 17:15:23.42
あと、Win版のPortableGit-1.7.6-preview20110709は、git-bashを起動しても、
bash:tset:command not found
と出て動作が止まってしまうんだが、これって俺だけですか？
90 :デフォルトの名無しさん2011/08/16(火) 20:06:56.84
HEAD^ の ^ がシェルで何かに解釈されてるんじゃないの?
やるなら git reset --hard 'HEAD^' とか。
> 88
古い UNIX マシンからそのままコピーしてきた .bashrc あたりが残ってるとか。
.bashrc あたりで test と tset を間違えてるとか。
93 :デフォルトの名無しさん2011/08/16(火) 21:07:37.52
Win版のgit-bashで起動時のカレントディレクトリを変更するには、どこをどういじればいいでしょうか？
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 :952011/08/20(土) 13:06:07.35
>>96
davでの公開って、共有スペースにbareを置いてるだけなので
あまり期待できないっぽいですね。
pushを途中で切断したり、耐久テストしてたらやっぱり壊れました。

他にはdavのPUTできる場所を限定して、DELETEを禁止とかで
なんとか運用できないものかと考えてます。
98 :デフォルトの名無しさん2011/08/20(土) 13:32:54.37
Gitの仕組み上、pushを途中で切断して壊れるってのは無いと思うけどなー
99 :952011/08/20(土) 16:15:35.83
>>98
davがLOCKしたままになってたようです。
timeoutを設定しました。
100 :デフォルトの名無しさん2011/08/25(木) 12:50:21.30
次期OSS標準はそろそろ決まって欲しい
今の勢力って git>hg>bzr なかんじ？
104 :デフォルトの名無しさん2011/08/27(土) 03:10:23.55
gitのややこしいコマンド体系、というか破綻してるコマンド体系を
なんとかしようという動きはないのかな。
108 :デフォルトの名無しさん2011/08/27(土) 17:12:14.06
>>104
EasyGit
http://people.gnome.org/~newren/eg/
106 :デフォルトの名無しさん2011/08/27(土) 15:08:42.70
慣れると、つーか、開発のスタイルをgitに合わせないといけなくて、
そのスタイルでやるとすんなり来る感じ。
gitのモデルとする開発スタイルは従来のバージョン管理システムとはわりと違う感じ。
107 :デフォルトの名無しさん2011/08/27(土) 16:56:18.65
そういう問題じゃなくてだなぁ、他の分散管理に比べてもコマンド体系がおかしいんだよ
信者もいるし、gitの気持ち悪さは暗黙の了解だけとも
110 :デフォルトの名無しさん2011/08/27(土) 19:23:41.66
>>107
詳しく
116 :デフォルトの名無しさん2011/08/27(土) 22:17:31.40
>>107
多いのは信者じゃなくてアンチだろｗ
コマンドの数が多いとか難癖つけてさ。
おおかたウインドウズ大好きでC++信者なんだろうが、
頑張ってDISってる姿は滑稽だよ。
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 :1112011/08/27(土) 20:48:04.37
>>112 分かりました
ありがとうございます
118 :デフォルトの名無しさん2011/08/27(土) 23:49:04.17
>>111
そういう時はgit bundle使うんじゃなかったっけ
121 :1112011/08/28(日) 08:40:26.10
>>118 man読みました
まさにこれがやりたかったんです
ありがとうございます
119 :デフォルトの名無しさん2011/08/28(日) 01:01:55.19
preview20110708ベースのUTF-8ファイル名対応版 Gitで
日本語ファイルやディレクトリのaddやcommitはできるんだが、
日本語ディレクトリを含むパスでのinitができないのは俺だけ？
122 :デフォルトの名無しさん2011/08/28(日) 09:05:35.14
>>119の書き込み見てUTF-8対応版の最新版が来てたのを知った
?
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のようなゴミも渡すけど。
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しなければいいよ
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
おおこれは。ありがたいです。
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してみろ
ついでに後者なら鯖管に報告しろ
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 :1362011/09/06(火) 20:37:50.52
>>137
reflog でググりました
安心して失敗しまくることにします
140 :デフォルトの名無しさん2011/09/06(火) 22:08:09.03
pre-commitフックで拒否するとか。自分はマスターブランチへのコミットは全部弾いてる。
141 :デフォルトの名無しさん2011/09/08(木) 16:48:59.16
GitHubからのNotificationsが、メールアドレスにも転送されてくるのですが、これを停止する方法はありませんか？
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なんだから
149 :1462011/09/13(火) 09:56:30.65
>>147
なるほど。そこらの仕組みがよくわかってなくて
Cygwinのパッケージが少ないのがmsys、ぐらいのイメージだった。
そうするとやっぱり日本語は望み薄だな…
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 そうすればオブジェクトは残る。
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
159 :デフォルトの名無しさん2011/09/20(火) 11:38:10.98
乗っとられたままというか、乗っとられていない状態に戻すのに時間かかってるのだろ
162 :デフォルトの名無しさん2011/09/21(水) 19:46:00.78
今までずっとCygwinでgit使ってきて、今日初めてLinux上でgit使ってみたら速すぎて吹きました。
Cygwin上での遅さ(リーナスが発狂するレベル)を改善するテクニックみたいなのがあれば教えてください。
166 :デフォルトの名無しさん2011/09/21(水) 22:17:52.69
>>162
cygwin を窓から捨てろ
167 :デフォルトの名無しさん2011/09/21(水) 23:03:45.36
>>166
確かにhgの方がWindowsフレンドリーみたいですね…
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
莫大なファイルを読み書きするところがネックだと思う
でもそこってメイン処理なんじゃ…
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/
172 :デフォルトの名無しさん2011/09/22(木) 11:20:51.56
ああ、そういえばgccもcolinux上で動かした方がCygwin/MSYSよか速かったなあ。
そっちでgit試してみます。
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で扱うようになったから
いずれはまともに使えるようになるかもしれない
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に失敗するようになった
なんにもしてないのに。
181 :デフォルトの名無しさん2011/09/25(日) 21:22:26.62
この部屋は俺以外いないはずだけど

hideDotFilesって何のパラメータ受け入れてくれるんだよ
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/
197 :デフォルトの名無しさん2011/10/05(水) 19:52:58.80
>>190
クエスチョンなんか付けてるからrumorかとおもた
198 :1902011/10/05(水) 21:49:32.90
>>197
ChromeのCreate Link拡張使ったらそうなった。
書きこむ前はついていなかったのに、-が?に変化した
193 :デフォルトの名無しさん2011/10/05(水) 05:11:58.79
最近 Github が人気になりすぎたのか重くてしょうがない。
Buildbot のソースに使うのもはばかられてきた。
195 :デフォルトの名無しさん2011/10/05(水) 09:55:55.19
gitosisって2年くらい前で更新止まってなかったか
ほぼ上位互換で更新も続いてるgitoliteのほうがいいだろ
196 :デフォルトの名無しさん2011/10/05(水) 19:47:52.13
gitolite なんてファイルサーバにレポジトリを直置きするのとあんま変わんないじゃん
Gitorious のほうがいいって
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
ディレクトリ単位でプロジェクトを分けたい（一つのリポジトリに複数プロジェクトをいれたい）
のですが、そういうことはしない方がいいですか？
204 :デフォルトの名無しさん2011/10/07(金) 20:27:43.80
AというプロジェクトとBというプロジェクトとCというプロジェクトに関連性を持たせたいなあと考えたことはある
現行では素直にディレクトリ分ける以外に方法がないわけだが
207 :デフォルトの名無しさん2011/10/08(土) 13:04:33.00
すみません。とても基本的なことですが、
bashにて、git blame を実行すると、末尾に(END)が出てきて入力を受け付けず
抜けられない状態に陥ります。
ここから抜ける方法を教えてください。
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
サンクス！
さっそくパクらせてもらうわ！ザマー！！！！ｗｗｗｗｗｗ
219 :デフォルトの名無しさん2011/10/09(日) 08:08:07.92
Gitで管理しているディレクトリを動かしても問題は起きませんか？
たとえばhome/mysite/以下のディレクトリを管理している状態で（home/mysite/.git/ディレクトリがある状態で）
mysite/以下をdoc/ディレクトリに移動させたり、
mysite/ディレクトリそのものをmysite8/にリネームしたりしても。
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/

このエラーは何が原因でどうすれば回避できますか？
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が散らばっててもさほど困らないしステージングも冗長かもしれない。
233 :デフォルトの名無しさん2011/10/09(日) 22:53:19.09
ある程度のプロジェクトの規模が大きくないと恩恵少ないかもね
ソースがプログラマ一人の脳みそで足る量を超えたあたりから便利になるかも
235 :デフォルトの名無しさん2011/10/09(日) 23:15:52.92
どうせ一回のコミットごとに申請書提出するような職場なんでしょ？
だったらsvnでいいよ
236 :デフォルトの名無しさん2011/10/09(日) 23:27:00.92
良く分からんがgitでリモートリポジトリにコミットするのと
svnでサーバーにコミットするのとは同じことじゃないの？
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はツールに過ぎない。
コミュニケーション手段は別。
252 :デフォルトの名無しさん2011/10/10(月) 09:05:23.07
>>242
視野の狭いやつだなw
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だと、修正範囲の狭いシンプルな複数のパッチが好まれる。様々な修正が含まれたごった煮パッチ１個にまとめてコミットすると嫌がられる。
253 :デフォルトの名無しさん2011/10/10(月) 09:17:48.90
>>243
patch 何て使わずに rebase -i でいいだろ
260 :2412011/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)を同じぐらいの粒度ですればいいのではないかと思った。
よく考えたら試行錯誤中のこまめなコミットなんかするわけないしな。

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

もちろんそのとおりなんだが、
こういうのは「マージに時間がかかって遅れました」と平気で人事にするからな・・・
これは明らかに人の問題だから啓蒙するしかないか。
244 :デフォルトの名無しさん2011/10/10(月) 08:14:21.35
>>まちがえたpushで中央の履歴がカオス
そうなる前との差分をコミットして、その段階までリセットしてやりなおせばいい。

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

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

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

秘密的に非公開で作業し続ければ、この差を修正する作業を、（本来各自に任せられてた作業をわざわざ）一人で請け負うことになる。
これは明らかに損。
ローカルで秘密的に作業する時間が長ければ長いほど、中央との差は広がり、差を埋める作業という労力が増す。
246 :デフォルトの名無しさん2011/10/10(月) 08:32:39.02
なんでこんなに中央を直接更新するのを恐れてるのか分からない
別にコミットミスしてもその旨をコミットメッセージに書いて元に戻せばいいだけじゃねえの
ローカルとリモートで２重管理して生産性落ちるだけじゃねえの
git使ったら開発期間が延びてコスト増大で会社が倒産するわｗ
251 :デフォルトの名無しさん2011/10/10(月) 08:50:21.16
>>246
君が想定/経験している規模の開発だとミスがそんなに大した問題にはならないのかもしれない。
ローカルとリモートで2重管理しているように感じる体制だと確かに面倒に感じるかもしれない。
257 :デフォルトの名無しさん2011/10/10(月) 11:58:51.44
>>246
試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
まあそう考えないということは履歴なんか見ないんだろうがね。
267 :2412011/10/10(月) 12:47:55.40
>>257
> 試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
> まあそう考えないということは履歴なんか見ないんだろうがね。

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

「いずれ公開されるから、後で整理するのが嫌なら中途半端なコミットはするな」
「gitの便利さを享受したければpushの前に整理しろ」
という運用ルールにすればいいのかな
270 :デフォルトの名無しさん2011/10/10(月) 13:01:20.54
>>267
Gitは「後で整理する」のが容易なようになってるから後で整理するのも良し、
add -p で最初から良い感じのコミット組み上げていっても良し。公開前は個人の裁量。

ただし、プロジェクトの運営ルールは柔軟に決めればいい。超々タイトなスケジュールを
複数人でやっつけるなら奇麗なコミット云々言ってられないだろうし、その状況では
頻繁な公開=中途半端なコミットのpushが必要になる。
その後のリリースの段階ではやはりそういう履歴は不要になるから、いったんsquashなり
するかも知れない。雑だけど有用な履歴だと判断したらそのままにするかも知れない。
247 :デフォルトの名無しさん2011/10/10(月) 08:36:45.47
君がsvnに慣れ親しみすぎて他に移りたくないという気持ちはよく分かった。
実際に日本の会社ではsvnを使ってるだけでも褒められるレベル。
VCSすら使ってない会社はごまんとある。
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でいいんじゃないでしょうか？
291 :デフォルトの名無しさん2011/10/10(月) 19:06:37.78
>>256
よく分からんが今の状態を取りやめたいなら
git reset
でいいんじゃね？
259 :デフォルトの名無しさん2011/10/10(月) 12:20:12.89
テスト済みのコードに変更を加えていく場合とかで、レビュー済みのもののみを
履歴に残す形式で開発する状態になるとgitのスタイルがしっくりくる。
テスト済みなのにぐちゃぐちゃ変な変更が入っていくようなことをやる会社は倒産する。
261 :デフォルトの名無しさん2011/10/10(月) 12:26:56.93
結論としてはgitは不要ということだな
あれだろsvnと同じもの作ったらパクッたって言われるから
変な機能付けてオリジナルの画期的なソフトウェアができたとか主張してるんだろｗ
263 :デフォルトの名無しさん2011/10/10(月) 12:36:19.70
git reset --hard HEAD^で取り消したコミットに再び行き着くには、
git reflogでコミット一覧を表示して調べるしかありませんか？
266 :デフォルトの名無しさん2011/10/10(月) 12:45:30.33
>>263
だね。しかも--hardしてるってことは、addしてなかったファイルはもう手に入らない。。。
265 :デフォルトの名無しさん2011/10/10(月) 12:45:13.91
そんなにsvnが好きならalias使ってgitのコマンドをsvnライクにすればいいよ
268 :デフォルトの名無しさん2011/10/10(月) 12:51:45.59
中途半端なコミットなんかsvnでもgitでもありえるわけで
git使ったら解決されるわけでもないわけで
ステージングとかいうイミフな仕組みに工数とられるgitはうんこ
282 :デフォルトの名無しさん2011/10/10(月) 13:46:04.52
>>268
svnで中途半端なコミットなんかありえねーよ。
おめーtrunkのビルドこけさせたら死んで詫びろ。いいかわかったな
269 :デフォルトの名無しさん2011/10/10(月) 12:55:28.32
大体みんなで共有する中央リポジトリが存在する時点で集中型システムだろ
分散型とか言うから中央リポジトリなくてp2pみたいに開発者同士でネットワーク張ったりするのかと思ったのに
ただの面倒な２重管理だもんな糞ゲーだろ
271 :デフォルトの名無しさん2011/10/10(月) 13:04:47.64
>>269
「中央」リポジトリなどGitには無い。使う人がそう決めつけるだけだ。
無知でかわいそうなヤツ。
273 :デフォルトの名無しさん2011/10/10(月) 13:15:35.77
中央リポジトリがないってことはリリース時はどこから成果物を取り出すの？
成果物を取り出してる場所が中央リポジトリじゃないの
276 :デフォルトの名無しさん2011/10/10(月) 13:28:48.27
>>273
分散型やるならまず概念を変えないと先には進めないぜ
成果物は好きに取り出せ
中央だと思う場所があるなら、そこがお前にとっての中央かもしれんね
274 :デフォルトの名無しさん2011/10/10(月) 13:23:09.04
「gitイラネsvnでいい」と個人的に思ってるならまだしも
まわりにそれを押し付けるバカの多いこと
275 :デフォルトの名無しさん2011/10/10(月) 13:25:33.66
じゃあgitの良いところを教えてくれよ良いものは取り入れたいんだよ
２４００円も出して入門git買ってきたのにうんこ掴まされたんじゃ愚痴も言いたくなるよ
277 :デフォルトの名無しさん2011/10/10(月) 13:29:12.09
「入門Git」がうんこの一言で片付けられたらどうやってGitのいいところを伝えればいいんだよ…
DVCSをいかにして使うかよくわかる名著なのに
279 :デフォルトの名無しさん2011/10/10(月) 13:35:34.86
リビジョン番号も意味不明な文字列になってるし
過去のある時点にソフトウェアの状態を合わせたいときに
意思疎通しにくいだろ
280 :デフォルトの名無しさん2011/10/10(月) 13:38:35.42
リビジョン番号（笑）

分散してるのに採番とかしねーよ
284 :デフォルトの名無しさん2011/10/10(月) 14:25:09.84
結局、gitを使うと、svnで培ったオレ流を他の奴が守ってくれないかも
しれないから嫌だ。っていう文句しか言ってないのね。
どうせsvn使ったってオレ流を人に押しつけてるだけだから
うまくいかないのに、それをDVCSのせいにされてもねぇ。

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

VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ
いずれプロジェクトは滅茶苦茶になるさ。
それはDVCSのせいじゃない。
293 :2412011/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から劣化する点があれば対策を考えるよね。
？？？？？？？？？？？？
297 :2842011/10/11(火) 12:50:03.08
>>293
あなたを煽ったつもりはないです。
自分のプロジェクトはsvnが合ってるからsvnを使うよというだけの人を
どうこういうつもりはまったくないので。
VCS使わないって選択肢もありだと考えますし。

ただ、そのことをもって、
gitそのものをdisるキチガイが湧いていたので、
それに反論したのみです。
307 :デフォルトの名無しさん2011/10/11(火) 20:07:51.85
>>293
svnでの運用ルールが破綻してgitに乗り換えようとしたが
gitが難解でgitに八つ当たりしているのですね？
316 :2842011/10/11(火) 23:49:37.35
>>293 はまともなsvn使いがgitへの移行を検討するに当たって
gitの実運用上の問題を挙げてるにすぎないんだから、
これ以上煽ってやるな、真面目っぽいからかわいそうだ。
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^^の方がいいかな？
288 :デフォルトの名無しさん2011/10/10(月) 14:34:20.57
>>286
git checkoutだろ
295 :デフォルトの名無しさん2011/10/11(火) 10:19:13.55
とりあえずオープンソースで今時svn使ってるプロジェクトはうんこ
パッチ書いて送ったら「tortoise diffじゃないとヤダヤダ」とかぬかすような連中ばっかり
298 :デフォルトの名無しさん2011/10/11(火) 12:52:01.85
gitは無駄に２重管理する生産性の低いうんこだし
git使って開発してるやつはもっとうんこです
301 :デフォルトの名無しさん2011/10/11(火) 13:04:10.15
何をやりたいのか分からないな。
svnを褒め称えてgitをdisればみんながgitを放棄してsvnへ流れてくれるとでも思っているのだろうか。
306 :デフォルトの名無しさん2011/10/11(火) 19:41:48.17
派遣先用と自社用に２枚勤務管理表を書かないといけないだろ？
308 :デフォルトの名無しさん2011/10/11(火) 20:35:54.93
二重管理最高だろ。
svnのコミットするのに申請書が必要な環境では
ローカルリポジトリと共有フォルダ内work内のbareリポジトリで
実質的な管理をするもんなんだよ
309 :デフォルトの名無しさん2011/10/11(火) 20:56:01.10
２重管理求められる環境とか経験ないんだけど申請書？とか必要ない環境だったら２重管理のメリットなんか何もないってことだよね？
２重管理とかマージするときに競合が起きた場合の面倒臭さがより増大するだけじゃないの
318 :デフォルトの名無しさん2011/10/12(水) 00:05:01.21
俺には>>298とか>>309への反論に見えるな

素人考えでもマージするときの面倒さはsvnもgitも変わらないように思えるんだが
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 は無理だろう
と、思うことはある
バージョン管理は二の次だったりする所もあるからなあ
レベルは決して低くない所だが
317 :デフォルトの名無しさん2011/10/12(水) 00:04:26.67
いや、svnのコンフリクトを防ぐために運用ルールを定めているのであれば、それはツールに使われている。
欠陥ツールであるsvnを破棄してgitに移行すべきであろう。
319 :デフォルトの名無しさん2011/10/12(水) 00:41:17.03
マージ作業自体の手間はかかるにしても一旦コミットしてからマージできるから
リモートにブランチつくったりローカルの変更を手で保存したりしなくても
変更が失われないってのは結構な利点じゃない？
320 :デフォルトの名無しさん2011/10/12(水) 08:00:56.75
gitはTortoiseGitとmsysgitの２重管理のうんこ
322 :デフォルトの名無しさん2011/10/12(水) 08:54:23.81
>>320
2重管理という用語を使ってる君自身がその用語をちゃんと定義しきれていない気がするよ。
もうちょっと正確に言ってもらわないと、君が疑問に思っていることがあっても残念ながら中々答えてあげられない。
414 :デフォルトの名無しさん2011/10/17(月) 18:39:45.51
>>322
427 :デフォルトの名無しさん2011/10/18(火) 13:09:33.26
>>322
321 :デフォルトの名無しさん2011/10/12(水) 08:33:09.15
tortoisegit がうんこだったのは同意。ログ見るときと日本語で commit message 書くときくらいしか使ってなかった。
入れ替えるモチベーションなくしてんだが、最近のはどーなんだろ?

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


ところでロック厨がわいてくるだろうと蒸し返すw
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の長所だと主張してんだろ？
そこは納得いく説明をしてくれないと
331 :デフォルトの名無しさん2011/10/12(水) 14:03:05.74
>>327
gitだけの特徴じゃないんだよ。
333 :デフォルトの名無しさん2011/10/12(水) 14:07:09.37
>>331
svk
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
回線が切れてても中央のリポジトリから最新版を取ってきたりコミットできるの
履歴を簡単に書き換えられて過去のある版を取り出したくなったときとか困らないの
事故を減らせる代わりに面倒臭くなってるよね
332 :デフォルトの名無しさん2011/10/12(水) 14:03:16.03
>>330
履歴の書き換えはローカルだけだから無問題
タグが何のためにあるのか考えよう
タグを見るためにいちいちsvn listコマンドなどを叩いてリモートに見に行く方ががよっぽど面倒
334 :デフォルトの名無しさん2011/10/12(水) 14:32:19.88
回線が切れてたらさすがにリモートの最新版は取ってこれないが、log,diff,(ローカルに現存してるコミット間での)mergeなんかは使える
というかリモートリポジトリを必要とするpull/push以外の全機能が使えるしそういうコマンドはもともと通信しない
335 :デフォルトの名無しさん2011/10/12(水) 14:40:32.34
リモートを書き換えないなら何もしてないのと一緒じゃん
ローカルのものをいきなり成果物として客にリリースしたりするの
345 :デフォルトの名無しさん2011/10/12(水) 15:12:12.23
>>335
回線のつながってない客先にどうやって納品するの？
まさかzip？
それで客先で改変してカオスになるわけだ。
350 :デフォルトの名無しさん2011/10/12(水) 15:36:58.20
>>335当たり前のことだが、リモートに全く接続しないわけでなく、リモートに接続する頻度が減るだけだからな。
336 :デフォルトの名無しさん2011/10/12(水) 14:43:33.10
プログラミングにおいて一切の試行錯誤をしないのか？

ああ、与えられた仕様書をコードに起こすだけのコーダなのか
gitはそういうコーダのためのツールじゃないから
337 :デフォルトの名無しさん2011/10/12(水) 14:45:06.48
回線切れてるならsvnだろうがgitだろうが手旗信号でも使わないかぎりリモートと通信できるはずないだろｗ
347 :デフォルトの名無しさん2011/10/12(水) 15:16:49.69
>>337
bundle
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してやればいい。

管理されるのは、ごちゃごちゃな試行錯誤より、整理された試行錯誤のほうがいいよ。
362 :デフォルトの名無しさん2011/10/12(水) 18:35:38.48
>>360
その「最後は綺麗にしてコミット」するのが圧倒的に楽なのよ。
Gitで>>342のやり方をすれば。
343 :デフォルトの名無しさん2011/10/12(水) 15:00:29.63
実際それでうまくいってるし２重管理の必要性を感じない
マージするより#if #else でパッと見で分かる方が早いじゃん
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
377 :デフォルトの名無しさん2011/10/13(木) 19:55:32.92
>>372
それは誤読もいいところ。
そこに書いてあって1.7で実現されたgit的なものは
.svnがひとつになったことぐらい。
これは無条件に良くなったと言える。
387 :デフォルトの名無しさん2011/10/14(金) 06:35:24.18
>>377
残念ながらsvn1.7ではsvnユーザが行っていた２重管理はできなくなりました。
> **警告**: SQLiteライブラリを通じてSQLiteにアクセスがある間に、SQLiteのファイルをコピーするのは安全ではありません。
> 結果として、 Subversionプロセスからアクセスされているワーキング・コピーの複製を作る事(tar, rsync, cpなどで)は、
> Subversion1.7ではサポートされません。それは壊れている可能性があります。(課題 #3596)
344 :デフォルトの名無しさん2011/10/12(水) 15:05:21.76
Gitは漠然とした仕様の中手探りで開発するときに向いている。
自分でソフトウェアやプラグインを作るときは仕様の変更や試験的な実装がしょっちゅうあるだろ。
346 :デフォルトの名無しさん2011/10/12(水) 15:15:33.01
いつまで小学生構ってるんだよ・・・
348 :デフォルトの名無しさん2011/10/12(水) 15:19:01.27
>>346
ここはまんこスレだから
351 :デフォルトの名無しさん2011/10/12(水) 15:38:50.88
じゃあお前ら#if #elseで処理を有効/無効化したりコメント化したりせずに
わざわざ現状をローカルコミットして処理を消して書き直したりしてんの？
コードに残しときゃすぐ分かるのにバカじゃね
352 :デフォルトの名無しさん2011/10/12(水) 15:48:55.65
>>351
Linuxカーネルでは#ifは禁止。
コミットログに書いて十分なものを、コメントに書くのは馬鹿。
コメントはメンテされていないことがほとんど。信用できない。
356 : 忍法帖【Lv=40,xxxPT】 2011/10/12(水) 16:24:46.00
>>351
そんな意味のないプリプロセッサ付けんな! ソースが汚くなって見辛いし、ほんとに大事なものが見えなくなる。
357 :デフォルトの名無しさん2011/10/12(水) 16:31:32.11
>>351
ファイルが無駄にでかくなるし、そもそも修正履歴が追えないだろ
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使ってるんだ？
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使うのはうんこ
364 :デフォルトの名無しさん2011/10/12(水) 20:01:29.80
どんだけ大規模な試行錯誤してんの？
#if #else自体もほとんど使う機会ないんだけど
ローカルでそんな大規模な修正してて中央にコミットするときに競合した場合に
ものすごく面倒臭いんじゃないの？競合相手も大規模な試行錯誤してんだろう？
369 :デフォルトの名無しさん2011/10/12(水) 20:55:48.66
>>364
数行の修正×数箇所とか程度の簡単な修正でもGit使うと楽よ。
エディタでソース修正してローカルなコミットを作った後は、
動作確認して必要なコミットだけをまとめてコメント付け直してリモートに登録するとかを
コマンド叩くだけでできるし。

#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
神聖なまんこスレからうんこは排除せねばならない
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とか使っちゃう
と思う。
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 の表示結果からして違うせいなのか、
デバッグ用の実行ファイルになってるのかな
379 :デフォルトの名無しさん2011/10/13(木) 21:26:01.98
1.7のリリースまでにはまとめられなかっただけだろ。
2重管理とやらをしてないのに。
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
389 :デフォルトの名無しさん2011/10/14(金) 07:10:39.64
>>386-387
いいかげんウザい
馬鹿に付き合ってるお前も馬鹿に見えてるのに気付け
380 :デフォルトの名無しさん2011/10/13(木) 21:29:40.03
2重管理地獄の中で悶えて死ね
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のテストコード」
とかは同じコミットにすべきだし、単体で意味のあるバグ修正なんかは別のブランチに
してマージしたい。俺は。
388 :デフォルトの名無しさん2011/10/14(金) 06:39:26.99
>>383
最終的には科学的な指標なんてなくて、美的センスの問題。

383の改行が、いうなれば、パッチ整理のようなもの。

１改行は、それぞれが強く関連する、小さな意味単位としての分割。
２改行は、それらのグループ間での分割。

パッチの分割も３８３の文章と同じ要領。結局これは、最後は美的センスの問題になる。
機械的で具体的な数字には示し難い。
385 :デフォルトの名無しさん2011/10/14(金) 04:30:35.56
公開リポジトリまたは他人のリポジトリには、基本、
「この機能いらないからこのコミットだけ却下」
ということができるようにローカルで調整してコミットしたブランチを送りつける

いやもちろんプロジェクトのポリシー次第なのだが
単一の機能を実現するためにあちこちいじらないといけないときは説明的なコミット満載の単一のブランチにしたりもする
あちらでsqashしてくれるんだろうと思ったらそのままブランチごと適用されてお茶吹いたりもするのであんまり勧めない
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開発者は馬鹿。
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 ってたまたまハッシュ値が衝突しちゃった場合ってどうするようになってるの？
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
おまえみたいに調べて訂正してくれるやつがいるから
ある意味 問題ないな
407 :デフォルトの名無しさん2011/10/16(日) 20:36:16.79
うん？コミット時にはエラーでなくてあとで困るってこと？
それってまずくね
409 :デフォルトの名無しさん2011/10/17(月) 09:12:15.64
SHA1ハッシュが衝突したとしてもオブジェクトの種類が違ったら
たぶんエラーになるから、さらに確率は下がるかな。
410 :デフォルトの名無しさん2011/10/17(月) 13:16:40.23
悪意を持って衝突させる奴が出たらそんなこと言ってられない
417 :デフォルトの名無しさん2011/10/17(月) 23:54:08.81
>>410
意図的にSHA-１を衝突させるとか何者？
418 :デフォルトの名無しさん2011/10/18(火) 00:00:29.53
>>410
できないできない絶対できない
やれない気持ちの問題じゃない
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
の間に要らなくなったブランチを削除しておくのが普通なのでしょうか?
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してる。
413 :デフォルトの名無しさん2011/10/17(月) 13:30:07.71
2重管理で悶えてるじゃねーかｗ
416 :デフォルトの名無しさん2011/10/17(月) 22:46:10.96
>>413
無駄だ
420 :デフォルトの名無しさん2011/10/18(火) 00:11:19.82
たとえ将来、自由にハッシュを衝突させることができるようになったとしても
既存のリポジトリの内容を破壊できるわけでもなんでもないその行為になんの意味があるの？
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を使い始めて日が浅いので、誤操作したのかもしれませんし、
正しく理解できていないところもたくさんあると思いますが、
ちょっと困惑してますので、ご教示ください。
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
概念がどうとかいうほどのもんかね？
433 :デフォルトの名無しさん2011/10/18(火) 19:32:13.07
>>431
いやだってbranchとは別物じゃない
435 :デフォルトの名無しさん2011/10/18(火) 22:49:25.35
あれからあらためてman読んだり自分で考えたりして、それなりにわかりました。
gitにはようするに「コミットオブジェクト」みたいなものしかないわけですよね。
タグはもちろんブランチも、ユーザのための記号みたいなもの。

だからブランチをつくったばかりなら、両ブランチは対等というかおんなじもので、
どちらが親とか、そういう意味もない。コミットした時点で初めて、
新たな「コミットオブジェクト」がつくられる。
あるコミットオブジェクトがどのオブジェクトから派生したか、といった情報は、
オブジェクトがつくられるときに記録される。

こう考えるとすごくわかりやすくなりましたし、シンプルでいいな、と思いました。
こんな感じに理解しましたが、だいたい合ってますでしょうか？
442 :デフォルトの名無しさん2011/10/19(水) 08:58:52.72
>>435
シンプルでいいよね。そこに気づけばもう迷うことはないよ。
必要に応じてコマンド覚えていけばいいだけ。おめでとう。
436 :デフォルトの名無しさん2011/10/18(火) 23:35:29.83
だいたい合ってる
しいていえばタグは特定のコミットをピンポイントで指すけど、ブランチはコミットの歴史（HEADの変遷）を指すってところかな
439 :デフォルトの名無しさん2011/10/19(水) 00:45:54.69
>>436
ありがとうございます。
タグとブランチの違いについても考えてましたけど、おおむね間違ってなかったみたいです。

使いかたはまだまだ練習中ですが、いろいろわかってきたので面白いです。
438 :デフォルトの名無しさん2011/10/19(水) 00:30:05.82
バージョン管理システム界にカオスと混乱を招いたgitの罪は重い
440 :デフォルトの名無しさん2011/10/19(水) 08:05:53.27
gitを理解できない奴の頭の中がカオスになってるだけだろ。
自分の頭の悪さを罪だと思えｗ
443 :デフォルトの名無しさん2011/10/19(水) 15:48:27.96
今一番使われているバージョン管理システムってgitなんすか
445 :デフォルトの名無しさん2011/10/19(水) 19:43:26.24
>>443
今一番使われてるのはSubversion
オープンソース開発でGitが増えている

一般の開発でもGitが増えつつある。
svn→gitは便利になることもある反面失うものも多いから
単純に置き換えが進むというものではなくてずっと共存すると思う。

過去、cvs→svnはなにも失うものが無かったから一気に移行が進んだ
444 :デフォルトの名無しさん2011/10/19(水) 16:07:14.60
ちょっと調べてみて使い方がスっと入ってこない時点でうんこ
446 :デフォルトの名無しさん2011/10/19(水) 20:05:51.00
失うものがないもっと良いやつ作れよ
何が分散型だよ中央とローカルで２つsvnリポジトリ持ってるのと一緒じゃねーかｗ
460 :デフォルトの名無しさん2011/10/19(水) 22:03:50.73
>>446
Mercurialならgitより失うものは少ないんじゃね
466 :デフォルトの名無しさん2011/10/20(木) 12:17:02.67
>>446
良いよ。いくら払う？
467 :デフォルトの名無しさん2011/10/20(木) 12:44:32.82
>>446
svkのこと？
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ってやってみ
こりゃ便利だと思うぞ
453 :デフォルトの名無しさん2011/10/19(水) 20:54:26.03
>>451
グラフがうんこになるのを推奨している記事か
452 :デフォルトの名無しさん2011/10/19(水) 20:47:39.83
で、あのおっさんがうんこと気づかずにメンテナ面して得意満面にいじくりまわしてるってか?

…ちがうだろ、基本設計が良かったから発展し続けてるんだろ?
俺は単にJunioのことをおっさん呼ばわりしたかっただけだw
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
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/がつくの？付けさせない方法ないの？
465 :デフォルトの名無しさん2011/10/20(木) 06:47:53.91
>>463
diff.noprefix のことだとは思うが後悔するなよ? tgit で試してないから知らん。
464 :デフォルトの名無しさん2011/10/19(水) 23:59:34.28
番号飛びすぎﾜﾛﾀwwww
まだ一所懸命やってるようだな。ご苦労なことだ。
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」だ。
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 :4822011/10/23(日) 21:40:50.26
なるほど、これといったルールはないんですね
ただのzipとかtarballでしか配布されてないものなんかも想定しているので、
自分がわかりやすいと思う分けかたでやっていくことにします
487 :デフォルトの名無しさん2011/10/26(水) 20:47:17.46
他の開発者との中央へのコミット内容が競合した場合の対応ってgitだとsvnより楽だったりしますか
490 :デフォルトの名無しさん2011/10/26(水) 21:57:09.24
>>487
楽だよ。3wayマージ賢い。
さすがに同じタイミングでがっつり同じ箇所ぶつかったら
手でマージすることになるけど、補助ツール使えばなんとかなる。
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したらどうなの？
497 :デフォルトの名無しさん2011/10/27(木) 22:20:26.99
>>495
新規モジュールでやられてしまうので
496 :デフォルトの名無しさん2011/10/27(木) 17:07:40.40
3wayマージは補助でp4merge使うと、ほとんど手修正しなくていいぞ
498 :デフォルトの名無しさん2011/10/28(金) 10:27:29.73
開発ブランチ(master)と、リリースブランチ(rel-X.X)とがあって、リリースブランチ（または開発ブランチ）に行ったcommitを、もう一方のブランチにcherry-pickしています。
このとき、両ブランチの間でどのコミットがcherry-pickされていて、どのコミットがされてないかを調べるいい方法はないでしょうか。
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
のようです。
ありがとうございました。
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
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するにはどうやればいいのでしょうか？
514 :デフォルトの名無しさん2011/10/30(日) 04:12:17.33
>>506
git clone --depth 1
その後出来ることに制限があるのでman見たりググったりしてくれ
507 :デフォルトの名無しさん2011/10/29(土) 15:12:07.97
なんだそりゃ
全ファイルの旧編集履歴をひとつの最新コミットに詰め込んで新たに履歴1個だけのブランチを作りたい？
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 の違いとは別なの？
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 してもそれらしいオプションはないし。困りました。
524 :デフォルトの名無しさん2011/11/01(火) 10:28:11.94
>>517
g log --decorate |grep "[ (]tag: "

じゃダメ？
518 :デフォルトの名無しさん2011/10/31(月) 21:42:56.10
git show タグ名
520 :デフォルトの名無しさん2011/10/31(月) 21:53:51.18
>>518
それはコミットとかのオブジェクトの中身を表示するコマンドですよね。
たしかにコミットIDも表示に含まれてますが、タグ名とコミットIDの一覧が表示できればそれでよくて、ファイルの中身とかは必要ないです。
ちょうど hg tags のように表示されればいいだけなんですけど、難しいでしょうか。
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してくるにはどうしたらいいですか。
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 ができてないかどうかチェキ
521 :デフォルトの名無しさん2011/10/31(月) 22:51:30.70
gitlab 試したヤシいる？
gitorious と比べてどうよ
540 :デフォルトの名無しさん2011/11/03(木) 07:10:13.88
>>521
コレ読んでここでなんか話題が出てないかと思って来てみたけど
あなたしかレスしていないね
http://www.moongift.jp/2011/11/20111101-2/
523 :デフォルトの名無しさん2011/10/31(月) 23:11:24.52
つか、
GITDIR/refs/tags の一蘭をふつうに得る。
GITDIR/packed-refs の中身をかっさばく
べたにやっていいんではないかと。refs/tagsの方が優先な。
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だけ一覧できる
531 :デフォルトの名無しさん2011/11/01(火) 17:36:04.12
>>529
-d つけないとタグとコミットの対応わかんないし、どっちにしろ同じコミットでも
全部別々の行になっちゃうから、>>527のほうが俺は見やすいな
536 :デフォルトの名無しさん2011/11/01(火) 23:14:15.39
>>531
tagってtag objectのことだったのか。
--dereference で何が困るんだ?
529 :デフォルトの名無しさん2011/11/01(火) 15:56:50.07
貴様ら git-show-ref を忘れてるだろ！！！
530 :デフォルトの名無しさん2011/11/01(火) 17:12:34.96
>>529
マジで忘れてたw

つかコマンドとオプション多すぎなくない？
569 :デフォルトの名無しさん2011/11/08(火) 15:03:09.65
>>567
うお、それそれ。これが見つかんなくて、>>566 と同じ事してて、
kernel treeだと、3万ファイル以上 checkout するんで
遅くて嫌になってたのよ。

助かったよ、ありがとう。
でも、>>530 じゃないけど、コマンドとオプション多すぎっつか、
逆引き git マニュアルとか欲しいよね。
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
537 :デフォルトの名無しさん2011/11/02(水) 14:55:42.99
git diffの結果を、ファイルか変更箇所ごとにマージするにはどうしたらいいんだろうか。
538 :デフォルトの名無しさん2011/11/02(水) 20:48:46.59
>>537
ファイルごとにaddしてcommitしてマージすればいいんじゃないの？違う？
541 :デフォルトの名無しさん2011/11/05(土) 18:24:22.73
Andoridアプリ開発しようと思ってeclipse落としたら
なんか最初からgit入ってるし
いつの間にかgitが主流になってきてるじゃねえか
まじやべえgitこわいよー
545 :デフォルトの名無しさん2011/11/06(日) 05:23:22.52
gitでも高性能な機能を使わなかったら一重管理できるよね。
俺はブランチも切らずただひたすらcommit -allしてるだけだし。
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
ぎっとなの？じっとなの？
554 :デフォルトの名無しさん2011/11/07(月) 21:07:00.25
>>551
http://ejje.weblio.jp/content/git
552 :デフォルトの名無しさん2011/11/07(月) 20:53:37.61
ぎっと、が一応正しい

「じっとはぶ」と読んでる人が大多数だと思うのだが、あれは「ぎっとはぶ」が正しい
555 :デフォルトの名無しさん2011/11/07(月) 21:27:45.63
github は、周囲では ぎっはぶ (トが落ちる)が多いなぁ。
全く知らなかったら ぎさぶ (thの発音で)と読んでしまいそう。
556 :デフォルトの名無しさん2011/11/07(月) 21:31:13.92
git
音節git 発音記号/git/

【名詞】【可算名詞】
《英俗》 ばか者，ろくでなし.
559 :デフォルトの名無しさん2011/11/07(月) 22:23:23.30
ギットでギットハブの俺にとってはこの流れがカルチャーショックなのだった。
561 :デフォルトの名無しさん2011/11/07(月) 22:37:11.41
git logだと増減したファイルのファイル名や修正されたファイルのファイル名が出ないのですが、
これを見るにはどうすればいいでしょうか？
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
でなくて？
570 :デフォルトの名無しさん2011/11/08(火) 15:13:36.72
ありゃ、ちょっと興奮して言葉遣いが荒くなってしまいました。
>>567の回答で助かりました。ありがとうございます。
573 :デフォルトの名無しさん2011/11/09(水) 07:47:05.98
addで追跡を開始したファイルの追跡をやめるにはどうすればいいでしょう。
ファイルを削除することなしで。
574 :デフォルトの名無しさん2011/11/09(水) 07:49:07.55
あ。すいません。すでにcommitされていてindexの中だけでなくリポジトリにも記録されてしまっているファイル
についての話です。
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重管理地獄で悶えて死ねｗｗｗｗ
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冊出ている
592 :デフォルトの名無しさん2011/11/16(水) 22:56:31.46
git svnでcloneして、色々書いてdcommitしたいんだけど、
その間適当なコメントでローカルにコミットしてたから、svnのlogには適当なコメントは反映させたくないんだ
どうしたらいい？
594 :デフォルトの名無しさん2011/11/16(水) 23:36:01.80
>>592
master は svn 追跡専用と割り切れ。
貴様 branch の上でせっせと禿んで dcommit の直前で squash.
dcommit 終わったら貴様 branch を rebase.
593 :デフォルトの名無しさん2011/11/16(水) 23:00:27.26
別ブランチ作って--squashでもすれば？
595 :デフォルトの名無しさん2011/11/16(水) 23:36:47.10
慣れたら branch 上でも svn dcommit を意識したコミットができるようになるってば。
597 :デフォルトの名無しさん2011/11/17(木) 07:38:45.76
>>593
>>594
ありがとう！助かった

>>595
まったく、おっしゃるとおりです。
601 :デフォルトの名無しさん2011/11/18(金) 01:24:02.17
>>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をパワーアップ……岡本 隆史
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使ってる人、みんなどうしてる？
605 :デフォルトの名無しさん2011/11/19(土) 11:37:31.30
作業領域からインデックスへのコミット
インデックスからローカルリポジトリへのコミット
ローカルリポジトリから中央サーバーへのコミット

の3重管理じゃねえかｗgitユーザーって馬鹿じゃないのｗｗｗ
610 :デフォルトの名無しさん2011/11/19(土) 13:24:23.65
インデクスはジャマだなーと思うことがある俺ガイル
歴史的には必要だっただろうけど
611 :デフォルトの名無しさん2011/11/19(土) 14:11:49.04
Gitのインデックスは後付けだが大発明だった。
インデックス使わないでどうすんの。
621 :デフォルトの名無しさん2011/11/19(土) 18:36:03.97
>>611
hgにはインデックスとかないけど、拡張のmqとrecordがあれば特に困らないし
612 :デフォルトの名無しさん2011/11/19(土) 15:09:25.27
なんで中央のリポジトリを直接いじることをそんなに怖がってるんだろう
みんなで中央をどんどん更新していって間違いが入ったらすぐ直せばいいだけじゃん
中央に間違いが入らないようにするために3重管理地獄を選ぶとかどうかしてるぜ
616 : 忍法帖【Lv=40,xxxPT】 2011/11/19(土) 16:10:38.17
>>612
そういう発想だから理解できないんじゃないかと思うが? 中央のリポジトリを触るのが怖い訳ではないと思うぞw
623 :デフォルトの名無しさん2011/11/19(土) 21:00:35.86
>>612
だから中央のリポジトリはコミットするのに査閲・承認が必要なんだって

あと管理表にない変数名を新規に定義することは許されないから
コミットする前に開発チームでローカルに命名した変数を
管理表にあるフォーマットに変換するリファクタリングのフェーズが必要だし。
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ってか？
お前に何を使えとか強要されたくないわ
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にあるような、部分的にコミットにステージングする機能はありません。
一部のファイルをコミットすることはできますし、プラグインを使えばファイル内の一部のハンクをコミットすることもできますが、コミットの一部をステージして作業を続ける方法はありません。
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重管理が前提条件になってるんだよ
直接中央コミットで問題起きたら即修正でなんら問題ないだろ
629 :デフォルトの名無しさん2011/11/19(土) 21:57:23.13
>>627
>直接中央コミットで問題起きたら即修正でなんら問題ないだろ

でかい開発したことないだろ。
ちょっとした規模の開発でそんなことしてたら、収拾つかんぞ。
637 :デフォルトの名無しさん2011/11/19(土) 23:26:44.54
>>627
いや、だから、何度も言うとおりコミットに査閲と承認が必要な環境があるんだよ
628 :デフォルトの名無しさん2011/11/19(土) 21:55:18.94
チーム内のはマイナーフィックスしたいときに容赦なくできるから便利ってことじゃないの？
で、メジャーフィックスを中央にコミットする。
630 :デフォルトの名無しさん2011/11/19(土) 22:06:10.68
そもそもそうそう問題なんか起きないし
リポジトリ上のプログラムは常にビルドが通るようにしておくのが基本だろ
そんな簡単なこともgitユーザーはできないのｗ？
631 :デフォルトの名無しさん2011/11/19(土) 22:12:48.96
>>630
> そもそもそうそう問題なんか起きないし

小さい規模しかやったことがない奴の意見乙。

>リポジトリ上のプログラムは常にビルドが通るようにしておくのが基本だろ

ビルド通るだけでいいと思ってるのが君の想像力の限界なんだな。
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使えばいいだけなのに、
何をそんなに騒いでいるのか分からないなぁ。
638 :デフォルトの名無しさん2011/11/19(土) 23:36:15.64
git使ったらコミットに査閲と承認が必要なくなるのかって。
それは運営方法の話だろ
バージョン管理システムの話してるんだけど馬鹿なの
639 :デフォルトの名無しさん2011/11/19(土) 23:55:06.16
TortoiseGitの1.7.5.0が出てた
もうバグが増えないといいな
652 :デフォルトの名無しさん2011/11/20(日) 10:08:38.68
>>639
それよりmsysgitのsvnが古いのを何とかしてほしい
svnが1.7で互換性をブチ切ったりしなけりゃ古いままでも問題なかったんだが
640 :デフォルトの名無しさん2011/11/19(土) 23:55:17.27
チーム内のソース共有とかコードレビューの時にコミットが必要になるだろ
そんな時いちいち承認とかしてられないだろ
で、チーム内ローカルのリポジトリがあって、ひと通りのレビューが終わってから中央リポジトリにコミットすれば楽だろ
そういう時にチーム内ローカル→git 中央リポジトリ→svnだと管理が楽なんだよ
ローカルリポジトリをsvnにしてしまうと中央リポジトリへの反映が大変だし。

本当は中央リポジトリもgitにしてもらうか、承認を簡単にしてもらうほうがいいんだけど
中央は発注元だしあちらさんの社内文化を変えてもらう労力のが大変で、
gitの二重管理で自分たちだけ防衛したほうが工数少ないでしょうとかそんな色々な理由。
641 :デフォルトの名無しさん2011/11/20(日) 00:00:42.44
>>640
なるほど。参考になった。
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
648 :デフォルトの名無しさん2011/11/20(日) 09:46:27.84
>>645
インストールされていることと、使われていることの区別も付かんのか。
649 :デフォルトの名無しさん2011/11/20(日) 09:50:10.31
>>648
gitはインストールされているけど、使われていない、使えないのですね。わかります。
646 :デフォルトの名無しさん2011/11/20(日) 09:37:15.15
母数がDebianのパッケージマネージャって時点で、お前の言うカスやボケが含まれると思うか？
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重管理してるのがそもそもおかしい
654 :デフォルトの名無しさん2011/11/20(日) 12:48:41.16
>>651
>Ａ，Ｂ，Ｃで3重管理してるのがそもそもおかしい

３重管理？
653 :デフォルトの名無しさん2011/11/20(日) 10:53:57.35
無料RPG製作ツール「ロープレジェネレーター」

直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力する
ことができます。(HSP製のソースコード付きで、スクリプトの知識があれば
自由度の非常に高いカスタマイズができます）
他にも仲間預かり機能（100人も）や、仲間の状態/状態異常を細かく設定
できたり、乗り物が作れたり、ゲーム中に画像を差し込んだり、回転や
フラッシュなどのエフェクトなんかも簡単に作れる様です。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
戦闘はデフォだとドラクエ系。

・次期バージョンのロープレジェネレーター2.00アルファ版2を公開しました。(2011/10/29)
657 :デフォルトの名無しさん2011/11/20(日) 19:00:05.40
そもそも分散リポジトリ使ってて、めんどくさいと感じたことなんかないんだが。
むしろ馬鹿が中央リポジトリにヘンなのコミットしても
自分とこだけは一時的に防衛できるので作業効率よくなった
659 :デフォルトの名無しさん2011/11/20(日) 19:16:42.95
あ、>>657に言ってるんじゃないので
658 :デフォルトの名無しさん2011/11/20(日) 19:15:59.00
うるせえ、「重管理」NGワードにすっぞ
660 :デフォルトの名無しさん2011/11/20(日) 19:24:18.13
>>658
してなかったのかよ、NGワード多重管理君。

もちろんもはやn重管理はネタだろ。
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厨は釣られないように)
674 :デフォルトの名無しさん2011/11/21(月) 15:18:01.46
>>664
mergeしない・branchしないってわかってる用途限定ならsvnに戻れる
他に大きな理由がなければ戻りたくはないが
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はありません
696 :デフォルトの名無しさん2011/11/29(火) 18:24:52.29
>>695
Gitスレで運用の話をしても満足する回答はないよ。総合スレ行ったら？
Git/Mercurial/BazaarはDAGだから、Subversionと同じ感覚だと違和感があるよ。
それこそ>>664のようにSubversionに戻れなくなるから。
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の後ににファイルを編集したので
もう一度コミットするとおかしくなってしまいますのでたすけてください
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
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をするものでしょうか？
673 :デフォルトの名無しさん2011/11/21(月) 13:50:00.33
>>671
全部まとめてひとつのリポジトリにしてしまうのが、さしあたっての管理は楽。
git-submodule という機構もあるが、初心者が使うとぜったい事故る。
682 :6712011/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されてしまうってことはございませんか？
675 :デフォルトの名無しさん2011/11/21(月) 16:03:18.66
リモートリポジトリからファイルを取得するときに

git clone C:\test\. ってやってるんですが
ローカルのディレクトリに一つでもディレクトリやファイルがあるとエラーになるので毎回ローカル側のファイルやディレクトリ(.gitも含む)を消してから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\.
です
676 :デフォルトの名無しさん2011/11/21(月) 16:39:04.24
それfetchとかpullとかするところ。cloneは初回だけ。
685 :6712011/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
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 :6892011/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 :6892011/11/29(火) 17:48:42.12
>>694
開発環境でのテストでは問題なかったのに、
本番環境へ持っていったら動かなかった場合、
本番環境上で直接修正を行う場合があります。

あとは、客先の担当さんが直接変更を加える場合があるので、
それを取り込む場合があります。

その場合、本番ブランチに一旦コミット後、開発ブランチへマージ、
機能修正等を行ったあと本番ブランチにマージといった流れでやってます。
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で本番ブランチに直接コミットすることが間違っているとは思うが。
697 :デフォルトの名無しさん2011/11/29(火) 23:36:55.67
なんかデスマテンプレートみたいな運用だな
確かに本番だけ動かん、というケースは存在するし、
結果的にぶっつけで本番直すことあるが、
根本的に手順が間違ってる。

スレチすまん。
698 :デフォルトの名無しさん2011/11/29(火) 23:38:41.40
＞マージしたときにどのリビジョンをマージしたかがプロパティに記録されるので、
＞次回マージするときにマージ済みの分は自動でスキップされます。

いつの間にかsubversionのマージも進化してたんだな
俺が使ってた頃はリビジョン範囲指定しなければならなくて
使いづれーなっておもってた

調べてみたら各フォルダにsvnができるのも改善されたんだな

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