11/08/27 20:32:36.72
>>111
それで全データ渡せるけど、無駄なモノもけっこう含まれちゃうかも。
渡す前にgit gcしとけば多少は無駄が省けると思う。
113:111
11/08/27 20:48:04.37
>>112 分かりました
ありがとうございます
114:デフォルトの名無しさん
11/08/27 21:48:14.57
Gitのコマンド面倒くさ
GUI使えないのかな
115:デフォルトの名無しさん
11/08/27 21:49:54.27
TortoiseGit
116:デフォルトの名無しさん
11/08/27 22:17:31.40
>>107
多いのは信者じゃなくてアンチだろｗ
コマンドの数が多いとか難癖つけてさ。
おおかたウインドウズ大好きでC++信者なんだろうが、
頑張ってDISってる姿は滑稽だよ。
117:デフォルトの名無しさん
11/08/27 22:34:58.85
まさに信者だな
118:デフォルトの名無しさん
11/08/27 23:49:04.17
>>111
そういう時はgit bundle使うんじゃなかったっけ
119:デフォルトの名無しさん
11/08/28 01:01:55.19
preview20110708ベースのUTF-8ファイル名対応版 Gitで
日本語ファイルやディレクトリのaddやcommitはできるんだが、
日本語ディレクトリを含むパスでのinitができないのは俺だけ？
120:デフォルトの名無しさん
11/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
11/08/28 08:40:26.10
>>118 man読みました
まさにこれがやりたかったんです
ありがとうございます
122:デフォルトの名無しさん
11/08/28 09:05:35.14
>>119の書き込み見てUTF-8対応版の最新版が来てたのを知った
㌧
123:デフォルトの名無しさん
11/08/29 22:43:10.78
>>120
いやコミットし忘れてるんならまずコミットしろよｗ
124:デフォルトの名無しさん
11/09/01 01:09:15.28
gitの管理を完全にやめるとき、あるいはリセットするとき、
.gitディレクトリを削除すればそれで完全にリセットできますか？
125:デフォルトの名無しさん
11/09/01 01:23:39.58
>>124
管理をやめるなら.gitを消せばいい。
リセットというのがどういう動作を指すのかわからんのだが、
仮にバージョン管理を始める前の状態に戻すという意味なら、
.gitを消すだけでは元に戻せない。
126:デフォルトの名無しさん
11/09/01 01:40:26.81
ありがとうございます。管理をやめるだけで、別にファイルは現状のままでいいので、
それで解決します。
127:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/09/01 15:19:15.22
>>127
cloneしなければいいよ
129:デフォルトの名無しさん
11/09/01 15:42:23.64
エスパーすると、githubにhttpsでアクセスしてる？
130:デフォルトの名無しさん
11/09/01 16:04:39.87
>>129
あ。してます。もしかしてGit Read-Onlyで出てくるアドレスの方を入力するべきなのか。
131:デフォルトの名無しさん
11/09/02 07:17:15.65
エスパーどころかエラー内容全部書いてるだろｗｗ
証明書が確認できないんだとさ、
取得できないならURLと権限を確認しろ
不一致か期限切れなら-fしてみろ
ついでに後者なら鯖管に報告しろ
132:デフォルトの名無しさん
11/09/02 07:19:30.44
エスパーしたのはgithubの部分か、
すまん早とちりだ
133:デフォルトの名無しさん
11/09/02 18:01:55.65
>>127
URLﾘﾝｸ(d.hatena.ne.jp)
134:デフォルトの名無しさん
11/09/02 18:35:14.59
>>133
おおこれは。ありがたいです。
135:デフォルトの名無しさん
11/09/04 14:46:51.52
git apply が当たらない
パッチ読んでもファイル読んでも絶対に適用できる自信がある小さなコミット由来なんだが、でも git apply -v でエラーが出る
…まあ、どうせどっかで間違えてるんだろうけど、ぜんぜん見えねえ
昼寝でもするか…
136:デフォルトの名無しさん
11/09/06 16:50:50.98
"main"と"test"というブランチがあるとして、
testで作業しててcommitやmergeしたら、じつはmainにいたので(略
みたいな事態を避けるために、
特定のブランチに対しては、特に明示しない限りcommitなどをさせない、
ようするに特定のブランチを保護しとくみたいな方法ってありますか？
まだgit自体使い始めでよくわかってないので、ヘンなこと書いてるかもしれませんが...
137:デフォルトの名無しさん
11/09/06 19:32:55.55
コミットをよそに晒してない限り reset も rebase もし放題だ。精一杯失敗しまくれ。
Gitではコミットはなかなか消えん。しばらくは git reflog がトモダチだな。
138:136
11/09/06 20:37:50.52
>>137
reflog でググりました
安心して失敗しまくることにします
139:デフォルトの名無しさん
11/09/06 21:07:40.73
俺はgit-completionでPS1書き換えてブランチ名出すようにしてるな。
140:デフォルトの名無しさん
11/09/06 22:08:09.03
pre-commitフックで拒否するとか。自分はマスターブランチへのコミットは全部弾いてる。
141:デフォルトの名無しさん
11/09/08 16:48:59.16
GitHubからのNotificationsが、メールアドレスにも転送されてくるのですが、これを停止する方法はありませんか？
142:デフォルトの名無しさん
11/09/08 17:24:43.02
あります。
143:デフォルトの名無しさん
11/09/08 19:10:09.91
教えていただきたいのですが。
144:デフォルトの名無しさん
11/09/08 19:36:24.39
設定画面を見れば一目瞭然だと思うのですが。
145:デフォルトの名無しさん
11/09/08 19:39:44.66
ああ。Notification Centerでしたか。
146:デフォルトの名無しさん
11/09/11 23:41:30.95
最近のCygwinはUTF-8だから日本語も問題が起きないんだよね？
てことはmsysがUTF-8になったらmsysGitでも日本語をUTF-8で使えるようになるの？
147:デフォルトの名無しさん
11/09/12 06:08:02.38
理屈はそうだが、msysはUTF-8にならないだろ。
VC++のランタイムをそのまま使うのがmingw、自前でPOSIX層を用意してるのがCygwinなんだから
148:デフォルトの名無しさん
11/09/13 02:53:48.52
gitにはclearcaseでいうmerge arrowという概念はある？
149:146
11/09/13 09:56:30.65
>>147
なるほど。そこらの仕組みがよくわかってなくて
Cygwinのパッケージが少ないのがmsys、ぐらいのイメージだった。
そうするとやっぱり日本語は望み薄だな…
150:デフォルトの名無しさん
11/09/13 10:31:53.47
システムロケール変更すりゃいいじゃん
151:デフォルトの名無しさん
11/09/13 22:03:46.41
今日git checkout .を誤爆して数時間の作業がパーになったんだけど、何とかして修復する方法はない?
152:デフォルトの名無しさん
11/09/13 23:10:59.72
>>151
そのファイルを一度もadd してなかったらどうしようもないな。
checkout もclean みたいに-f 必要だね…
153:デフォルトの名無しさん
11/09/14 08:58:57.49
>>151
-f がついてなかったら、未コミットファイルとの競合でチェックアウトは失敗すると思ったんだが…
checkout -f で上書きしちまったんだったら Git レベルでは修復の方法はない、ハズ。
まめに stash するんだなw そうすればオブジェクトは残る。
154:デフォルトの名無しさん
11/09/15 22:00:19.89
リポジトリに残っていないなら
復元ツールを使うとか
155:デフォルトの名無しさん
11/09/19 01:35:03.40
なんかずっとメンテ中になってるな、ダウンロードできん
156:デフォルトの名無しさん
11/09/19 08:10:47.08
>>155
Gitのソースコードのことなら、kernel.orgがハクられて落ちてる
こっちのミラーからダウソ推奨
URLﾘﾝｸ(ftp.iij.ad.jp)
157:デフォルトの名無しさん
11/09/19 09:53:36.00
kernel.orgはいつ復活するのかのぅ
いろんな所で影響出てる
158:デフォルトの名無しさん
11/09/20 11:31:20.00
まだ乗っ取られたままだったのか。
159:デフォルトの名無しさん
11/09/20 11:38:10.98
乗っとられたままというか、乗っとられていない状態に戻すのに時間かかってるのだろ
160:デフォルトの名無しさん
11/09/20 12:21:15.89
荒らされる前に戻すのが大変てことか
161:デフォルトの名無しさん
11/09/20 13:17:00.60
子供はじっとしてなさい
162:デフォルトの名無しさん
11/09/21 19:46:00.78
今までずっとCygwinでgit使ってきて、今日初めてLinux上でgit使ってみたら速すぎて吹きました。
Cygwin上での遅さ(リーナスが発狂するレベル)を改善するテクニックみたいなのがあれば教えてください。
163:デフォルトの名無しさん
11/09/21 20:05:09.32
Cygwinはファイル操作が致命的に遅いからねえ。
どうしようもないんじゃないのかな。
164:デフォルトの名無しさん
11/09/21 20:15:49.03
ボトルネックになる場所を特定してその部分だけでもcygwinをバイパスすればマシになるかもね
165:デフォルトの名無しさん
11/09/21 20:20:44.58
莫大なファイルを読み書きするところがネックだと思う
でもそこってメイン処理なんじゃ…
166:デフォルトの名無しさん
11/09/21 22:17:52.69
>>162
cygwin を窓から捨てろ
167:デフォルトの名無しさん
11/09/21 23:03:45.36
>>166
確かにhgの方がWindowsフレンドリーみたいですね…
168:デフォルトの名無しさん
11/09/21 23:46:03.85
Cygwinって、まだサポートされているのかよ？
穴だらけなんじゃね？
169:デフォルトの名無しさん
11/09/22 01:47:07.88
>>168
Cygwin使っている人いますか？ その20
ｽﾚﾘﾝｸ(unix板)
170:デフォルトの名無しさん
11/09/22 09:12:31.83
WindowsのForkがクソ重いんだっけ
171:デフォルトの名無しさん
11/09/22 10:03:15.11
forkよりstatの遅さの方が影響してるんでないかなぁ
172:デフォルトの名無しさん
11/09/22 11:20:51.56
ああ、そういえばgccもcolinux上で動かした方がCygwin/MSYSよか速かったなあ。
そっちでgit試してみます。
173:デフォルトの名無しさん
11/09/22 13:59:13.56
cygwinだとgit遅いのかー
というよりcygwinで開発とかすげーな
174:デフォルトの名無しさん
11/09/22 14:16:06.03
遅いと言ってもネイティブのSVNよりは早いと思った
175:デフォルトの名無しさん
11/09/22 15:16:08.05
Cygwin上で開発してるわけではないです。
Windows上で開発してるものをgitでバージョン管理している、というだけで。
(gccの件は過去の経験上、というだけで)
>>174
確かにそうですね。branchやcommitは即座に完了しますし。
ただgit使ってるとstashやらrebaseやら、
svnでは(機能自体無いので)使わなかった便利機能を使い出すと…という感じですね。
176:デフォルトの名無しさん
11/09/22 16:05:46.13
libgit2がWin32ネイティブ対応していてパスをUTF-8で扱うようになったから
いずれはまともに使えるようになるかもしれない
177:デフォルトの名無しさん
11/09/23 00:11:06.58
なに？なに？今度は期待していいの！？
178:デフォルトの名無しさん
11/09/23 01:33:44.94
現状はかなりカオス気味
VS2008以前でビルド通らないままだったり、
DLLは__stdcallなのにヘッダが__cdeclでリンク不能だったり
179:デフォルトの名無しさん
11/09/25 16:21:45.04
なんかtortoisegitである日から
fatal: bad config value for 'core.hidedotfiles' in ./config
ってメッセージが出てpushに失敗するようになった
なんにもしてないのに。
180:デフォルトの名無しさん
11/09/25 19:01:19.50
おまえ以外の誰かが何かしたんだろ
181:デフォルトの名無しさん
11/09/25 21:22:26.62
この部屋は俺以外いないはずだけど
hideDotFilesって何のパラメータ受け入れてくれるんだよ
182:デフォルトの名無しさん
11/10/01 23:15:32.00
1.7.7ｷﾀ━━(ﾟ∀ﾟ)━━!!
URLﾘﾝｸ(article.gmane.org)
> The latest feature release Git 1.7.7 is available.
> The release tarballs are found at:
> URLﾘﾝｸ(code.google.com)
> 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:デフォルトの名無しさん
11/10/01 23:18:07.55
今日1.7.6.4をソースからビルドしたばっかなのに・・・
184:デフォルトの名無しさん
11/10/01 23:19:08.62
何が新しくなったの？
185:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/03 07:02:35.26
よく七時間も粘ったね
187:デフォルトの名無しさん
11/10/03 07:55:02.82
野良構築された newlib.git 探してみては?
188:デフォルトの名無しさん
11/10/03 19:32:50.04
>>186
調べるとあり得ないレベルで遅いって話は聞いてたからでかいリポジトリだしそんなもんだと思ってた
ところが40MB*1500ファイル=60GBも転送していたという(ローカルのcvsミラーだが)
>>187
探したけどリリースのtarballから作ったリポジトリしか見つからなかったんだ
自分の環境に合わせて修正するのが基本のソースだから簡単に見つかると思ったんだけど
189:デフォルトの名無しさん
11/10/03 22:24:08.99
git cvsimport はインポート後の履歴が変だったことがあったから使ってないな
代わりに cvs2git 使ってる。インクリメンタルインポートできないのが難点だが
190:デフォルトの名無しさん
11/10/04 22:14:45.01
え？BitBucketもGitに対応したの
Bitbucket now rocks Git ? Bitbucket blog URLﾘﾝｸ(blog.bitbucket.org)
191: 忍法帖【Lv=32,xxxPT】
11/10/04 22:15:59.59
対応したと聞いて昼過ぎに登録してきたｗｗ
192:デフォルトの名無しさん
11/10/05 00:58:00.16
GitHub と比較してどうなの？
193:デフォルトの名無しさん
11/10/05 05:11:58.79
最近 Github が人気になりすぎたのか重くてしょうがない。
Buildbot のソースに使うのもはばかられてきた。
194:やんやん ◆yanyan72E.
11/10/05 08:00:53.58
自分の鯖か知人の鯖でgitosisにするのが吉
195:デフォルトの名無しさん
11/10/05 09:55:55.19
gitosisって2年くらい前で更新止まってなかったか
ほぼ上位互換で更新も続いてるgitoliteのほうがいいだろ
196:デフォルトの名無しさん
11/10/05 19:47:52.13
gitolite なんてファイルサーバにレポジトリを直置きするのとあんま変わんないじゃん
Gitorious のほうがいいって
197:デフォルトの名無しさん
11/10/05 19:52:58.80
>>190
クエスチョンなんか付けてるからrumorかとおもた
198:190
11/10/05 21:49:32.90
>>197
ChromeのCreate Link拡張使ったらそうなった。
書きこむ前はついていなかったのに、-が?に変化した
199:デフォルトの名無しさん
11/10/05 23:02:01.15
ギトギトしたスレだなぁ
200:やんやん ◆yanyan72E.
11/10/06 11:00:38.55
ほんとだ。gitosisって相当古いのね。暇を見つけてGitoriousに移行します。
201:デフォルトの名無しさん
11/10/06 12:53:07.12
Gitorious のインストールは手間がかかるから
丸一日くらい費やされると思っといたほうがいい
202:デフォルトの名無しさん
11/10/07 20:11:12.58
ディレクトリ単位でプロジェクトを分けたい（一つのリポジトリに複数プロジェクトをいれたい）
のですが、そういうことはしない方がいいですか？
203:デフォルトの名無しさん
11/10/07 20:22:05.15
いいです
204:デフォルトの名無しさん
11/10/07 20:27:43.80
AというプロジェクトとBというプロジェクトとCというプロジェクトに関連性を持たせたいなあと考えたことはある
現行では素直にディレクトリ分ける以外に方法がないわけだが
205:デフォルトの名無しさん
11/10/07 20:40:43.82
そうですか
ありがとうございました
206:デフォルトの名無しさん
11/10/07 22:13:56.81
submodule?
207:デフォルトの名無しさん
11/10/08 13:04:33.00
すみません。とても基本的なことですが、
bashにて、git blame を実行すると、末尾に(END)が出てきて入力を受け付けず
抜けられない状態に陥ります。
ここから抜ける方法を教えてください。
208:デフォルトの名無しさん
11/10/08 13:23:25.75
PAGERがlessなのかね?
q
209:デフォルトの名無しさん
11/10/08 14:28:37.87
revertは変更をアンドゥしているのではなく、中身は以前の状態にしているけど履歴的にはさらに新しい
変更をした状態にするってことでしょうか？
210:デフォルトの名無しさん
11/10/08 14:46:40.72
>>209
だいたい合ってるけど、「中身を以前の状態に」はしない。
逆方向のパッチを当てるだけ。なのでrevertで指定した
コミットとHEADの間にコミットがある場合は「元に」は
戻らない。
211:デフォルトの名無しさん
11/10/08 16:18:45.58
>>210
結果的に同じ tree を指すことになるのが常。
212:デフォルトの名無しさん
11/10/09 00:07:56.19
>>211
半年前のコミットをrevertしたと考えてみよう
213:デフォルトの名無しさん
11/10/09 01:47:12.53
git push した先のサーバー内の、
ログやデータを一部削除するためのgitコマンドを教えろ
コピペしてすぐ使えるような具体的なコマンドで説明よろ
214:デフォルトの名無しさん
11/10/09 01:52:09.01
>>213
ねーよカス
ガキは糞して寝ろ
215:デフォルトの名無しさん
11/10/09 02:17:10.09
>>213
ssh rm -fr /
216:デフォルトの名無しさん
11/10/09 02:25:54.68
>>215
サンクス！
さっそくパクらせてもらうわ！ザマー！！！！ｗｗｗｗｗｗ
217:デフォルトの名無しさん
11/10/09 02:41:49.73
おやすみ
218:デフォルトの名無しさん
11/10/09 03:04:06.38
おまわりさんこいつです！
219:デフォルトの名無しさん
11/10/09 08:08:07.92
Gitで管理しているディレクトリを動かしても問題は起きませんか？
たとえばhome/mysite/以下のディレクトリを管理している状態で（home/mysite/.git/ディレクトリがある状態で）
mysite/以下をdoc/ディレクトリに移動させたり、
mysite/ディレクトリそのものをmysite8/にリネームしたりしても。
220:デフォルトの名無しさん
11/10/09 08:12:22.98
大丈夫
221:デフォルトの名無しさん
11/10/09 11:06:42.49
sudo を入れないとこが良心的? まあ sudoer のわけないか。
222:デフォルトの名無しさん
11/10/09 14:28:11.33
その前にホスト名
223:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/09 16:08:17.20
すでにカレントディレクトリよりも上のディレクトリがgitの管理下になっているときには
下層のディレクトリをgit initすることはできないのですが、これはどうしてもそうなのでしょうか？
226:デフォルトの名無しさん
11/10/09 17:37:47.22
俺はホームディレクトリの .git でドットファイルを管理しつつ、
ホームディレクトリのなかにもいろいろ独立したgitリポジトリがあるんだが。
227:デフォルトの名無しさん
11/10/09 21:29:22.17
cvsとsvnは使ったことがあってgitは使ったこと無いんですが
gitに乗り換えた方が便利なんですかね
svnの次世代バージョンみたいな認識で合ってるんですかね
228:デフォルトの名無しさん
11/10/09 22:01:15.24
svnで何も困っていないなら無理に乗りかえなくてもいいと思う
229:デフォルトの名無しさん
11/10/09 22:23:14.54
とりあえず入門gitという本で一通り勉強してみたが
いまいちgitの良さが分かんないな
ステージという概念も単に冗長で面倒くさいだけとしか思えないし
分散バージョン管理システムと言いつつも結局複数人で開発するときは
リモートリポジトリ？を作って集中型のバージョン管理するわけだよね
リーナスという人の自己顕示欲を満たすためだけに作られた
ソフトウェアなんじゃないのと言ったら言いすぎだろうか
230:デフォルトの名無しさん
11/10/09 22:28:06.80
リポジトリ1本で全く困らないような開発体制＆思考体系なら集中型で過不足無いだろうし、
GUIから使うなら.svnが散らばっててもさほど困らないしステージングも冗長かもしれない。
231:デフォルトの名無しさん
11/10/09 22:35:25.93
GitHubを使えるのが大きな利点だと思うぞ。
232:デフォルトの名無しさん
11/10/09 22:53:11.19
svnで満足してるならsvn使ってればいいじゃないか
233:デフォルトの名無しさん
11/10/09 22:53:19.09
ある程度のプロジェクトの規模が大きくないと恩恵少ないかもね
ソースがプログラマ一人の脳みそで足る量を超えたあたりから便利になるかも
234:デフォルトの名無しさん
11/10/09 23:00:13.93
それはsvnでは駄目でgitでしか解決できないことなん
235:デフォルトの名無しさん
11/10/09 23:15:52.92
どうせ一回のコミットごとに申請書提出するような職場なんでしょ？
だったらsvnでいいよ
236:デフォルトの名無しさん
11/10/09 23:27:00.92
良く分からんがgitでリモートリポジトリにコミットするのと
svnでサーバーにコミットするのとは同じことじゃないの？
gitの方がコミット前にステージングという良く分からん手順が必要なだけで
237:デフォルトの名無しさん
11/10/10 00:17:55.94
add -p とか rebase -i とかやらないとgitのうれしさは分からん。
238:デフォルトの名無しさん
11/10/10 02:17:42.78
>>236
そのよく分からない部分を分かるようになるまで勉強するんだ
239:デフォルトの名無しさん
11/10/10 03:49:00.09
なんであるものxの良さがわからないと、
xなんて作ったやつの自己顕示だとかこき下ろしたりするんだ?
おまえがxのことを理解できなくても誰もバカになんかしてないぞ
240:デフォルトの名無しさん
11/10/10 04:07:53.26
ローカルにブランチが持ってこれるというのは俺にとって革命的だった
241:デフォルトの名無しさん
11/10/10 07:25:34.26
ローカルコミットできる便利さはよくわかるが
これによって発生する運用上の課題が
容易に容易に想像できるので気軽に
仕事で使う気にはなれないな。
手元のごみコミットを整理せずに
pushして中央の履歴がカオスとか、
ローカルコミットしただけで
push忘れて反映されないとか、
何週間もローカルで作業して
成果を見せない奴がててくるとか、
どうやって解決してるの？
全員がスキルの高いチームでしか使えない？
242:デフォルトの名無しさん
11/10/10 07:37:59.60
>>241
いい加減スレ違い。こっちでやれ。
バージョン管理システムについて語るスレ8 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
それは全てSVNでも言えること。
GitなどVCSはツールに過ぎない。
コミュニケーション手段は別。
243:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/10 08:14:21.35
>>まちがえたpushで中央の履歴がカオス
そうなる前との差分をコミットして、その段階までリセットしてやりなおせばいい。
>>push忘れで反映されない
普通はコード修正が完了したら、まっさきにpushしたいと思うはず。
もたもたしてると他人の修正とのバッティングで面倒に成りかねない。
>>何週間もローカルで秘密的に作業する奴
作業量が増えて損をするだけ。
他の人は、この人の秘密作業の修正コードを知らずに、各自が勝手に作業を進めて、中央（的な役割と決められた場所）へとコミットしてしまう。
中央との差は、中央に公開してしまえば、他の人も、その差を無くすように作業してコミットするが、
中央に公開しないままならば、他の人は、その差を考慮せずにコミットしてしまう。
秘密的に非公開で作業し続ければ、この差を修正する作業を、（本来各自に任せられてた作業をわざわざ）一人で請け負うことになる。
これは明らかに損。
ローカルで秘密的に作業する時間が長ければ長いほど、中央との差は広がり、差を埋める作業という労力が増す。
245:デフォルトの名無しさん
11/10/10 08:22:36.63
gitはsvnを面倒臭くした集中型バージョン管理システム
246:デフォルトの名無しさん
11/10/10 08:32:39.02
なんでこんなに中央を直接更新するのを恐れてるのか分からない
別にコミットミスしてもその旨をコミットメッセージに書いて元に戻せばいいだけじゃねえの
ローカルとリモートで２重管理して生産性落ちるだけじゃねえの
git使ったら開発期間が延びてコスト増大で会社が倒産するわｗ
247:デフォルトの名無しさん
11/10/10 08:36:45.47
君がsvnに慣れ親しみすぎて他に移りたくないという気持ちはよく分かった。
実際に日本の会社ではsvnを使ってるだけでも褒められるレベル。
VCSすら使ってない会社はごまんとある。
248:デフォルトの名無しさん
11/10/10 08:38:48.78
ごまんはねぇよ。
249:デフォルトの名無しさん
11/10/10 08:39:19.68
gitのスレでsvnの宣伝にきたのかこの人は
250:デフォルトの名無しさん
11/10/10 08:47:53.21
なんだ、最近はgitスレにまでドカタが湧いてんのか
251:デフォルトの名無しさん
11/10/10 08:50:21.16
>>246
君が想定/経験している規模の開発だとミスがそんなに大した問題にはならないのかもしれない。
ローカルとリモートで2重管理しているように感じる体制だと確かに面倒に感じるかもしれない。
252:デフォルトの名無しさん
11/10/10 09:05:23.07
>>242
視野の狭いやつだなw
253:デフォルトの名無しさん
11/10/10 09:17:48.90
>>243
patch 何て使わずに rebase -i でいいだろ
254:デフォルトの名無しさん
11/10/10 10:37:42.73
remoteに行く前のコミットはいじりまくって良いということに慣れないとな
255:デフォルトの名無しさん
11/10/10 10:47:07.29
むしろremoteにぐちゃぐちゃコミット送る人なんなのローカルの概念ないの
256:デフォルトの名無しさん
11/10/10 11:55:58.23
git reset --soft HEAD^は、なぜHEAD^なのでしょう？
今の状態をとりやめたいからHEADでいいんじゃないでしょうか？
257:デフォルトの名無しさん
11/10/10 11:58:51.44
>>246
試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
まあそう考えないということは履歴なんか見ないんだろうがね。
258:デフォルトの名無しさん
11/10/10 11:58:55.95
HEADから一つ戻すからHEAD^なんだろ
259:デフォルトの名無しさん
11/10/10 12:20:12.89
テスト済みのコードに変更を加えていく場合とかで、レビュー済みのもののみを
履歴に残す形式で開発する状態になるとgitのスタイルがしっくりくる。
テスト済みなのにぐちゃぐちゃ変な変更が入っていくようなことをやる会社は倒産する。
260:241
11/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:デフォルトの名無しさん
11/10/10 12:26:56.93
結論としてはgitは不要ということだな
あれだろsvnと同じもの作ったらパクッたって言われるから
変な機能付けてオリジナルの画期的なソフトウェアができたとか主張してるんだろｗ
262:デフォルトの名無しさん
11/10/10 12:31:00.91
svnみたいなウンコで満足出来るならDVCSいらない
263:デフォルトの名無しさん
11/10/10 12:36:19.70
git reset --hard HEAD^で取り消したコミットに再び行き着くには、
git reflogでコミット一覧を表示して調べるしかありませんか？
264:デフォルトの名無しさん
11/10/10 12:44:02.79
svnとgitが同じに見えるならお前の目は不要だな
265:デフォルトの名無しさん
11/10/10 12:45:13.91
そんなにsvnが好きならalias使ってgitのコマンドをsvnライクにすればいいよ
266:デフォルトの名無しさん
11/10/10 12:45:30.33
>>263
だね。しかも--hardしてるってことは、addしてなかったファイルはもう手に入らない。。。
267:241
11/10/10 12:47:55.40
>>257
> 試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
> まあそう考えないということは履歴なんか見ないんだろうがね。
コミットを気軽にできるGitの方がむしろ「試行錯誤だらけのイミフな変更」が
remoteに入りやすいんじゃないの？
そうならないためにはpushする前にpushする人が整理しないといけないんだよね。
正直、机上で考えてるだけだといい解決策が思い浮かばない。
「いずれ公開されるから、後で整理するのが嫌なら中途半端なコミットはするな」
「gitの便利さを享受したければpushの前に整理しろ」
という運用ルールにすればいいのかな
268:デフォルトの名無しさん
11/10/10 12:51:45.59
中途半端なコミットなんかsvnでもgitでもありえるわけで
git使ったら解決されるわけでもないわけで
ステージングとかいうイミフな仕組みに工数とられるgitはうんこ
269:デフォルトの名無しさん
11/10/10 12:55:28.32
大体みんなで共有する中央リポジトリが存在する時点で集中型システムだろ
分散型とか言うから中央リポジトリなくてp2pみたいに開発者同士でネットワーク張ったりするのかと思ったのに
ただの面倒な２重管理だもんな糞ゲーだろ
270:デフォルトの名無しさん
11/10/10 13:01:20.54
>>267
Gitは「後で整理する」のが容易なようになってるから後で整理するのも良し、
add -p で最初から良い感じのコミット組み上げていっても良し。公開前は個人の裁量。
ただし、プロジェクトの運営ルールは柔軟に決めればいい。超々タイトなスケジュールを
複数人でやっつけるなら奇麗なコミット云々言ってられないだろうし、その状況では
頻繁な公開=中途半端なコミットのpushが必要になる。
その後のリリースの段階ではやはりそういう履歴は不要になるから、いったんsquashなり
するかも知れない。雑だけど有用な履歴だと判断したらそのままにするかも知れない。
271:デフォルトの名無しさん
11/10/10 13:04:47.64
>>269
「中央」リポジトリなどGitには無い。使う人がそう決めつけるだけだ。
無知でかわいそうなヤツ。
272:デフォルトの名無しさん
11/10/10 13:09:42.02
無くたって現実には作るだろうよ・・・頭の固いやつだな
273:デフォルトの名無しさん
11/10/10 13:15:35.77
中央リポジトリがないってことはリリース時はどこから成果物を取り出すの？
成果物を取り出してる場所が中央リポジトリじゃないの
274:デフォルトの名無しさん
11/10/10 13:23:09.04
「gitイラネsvnでいい」と個人的に思ってるならまだしも
まわりにそれを押し付けるバカの多いこと
275:デフォルトの名無しさん
11/10/10 13:25:33.66
じゃあgitの良いところを教えてくれよ良いものは取り入れたいんだよ
２４００円も出して入門git買ってきたのにうんこ掴まされたんじゃ愚痴も言いたくなるよ
276:デフォルトの名無しさん
11/10/10 13:28:48.27
>>273
分散型やるならまず概念を変えないと先には進めないぜ
成果物は好きに取り出せ
中央だと思う場所があるなら、そこがお前にとっての中央かもしれんね
277:デフォルトの名無しさん
11/10/10 13:29:12.09
「入門Git」がうんこの一言で片付けられたらどうやってGitのいいところを伝えればいいんだよ…
DVCSをいかにして使うかよくわかる名著なのに
278:デフォルトの名無しさん
11/10/10 13:31:02.33
入門gitにうんこついてたのか
交換してもらえよ
279:デフォルトの名無しさん
11/10/10 13:35:34.86
リビジョン番号も意味不明な文字列になってるし
過去のある時点にソフトウェアの状態を合わせたいときに
意思疎通しにくいだろ
280:デフォルトの名無しさん
11/10/10 13:38:35.42
リビジョン番号（笑）
分散してるのに採番とかしねーよ
281:デフォルトの名無しさん
11/10/10 13:39:31.58
svn信者はアホってことが良くわかるな
282:デフォルトの名無しさん
11/10/10 13:46:04.52
>>268
svnで中途半端なコミットなんかありえねーよ。
おめーtrunkのビルドこけさせたら死んで詫びろ。いいかわかったな
283:デフォルトの名無しさん
11/10/10 13:51:11.94
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ そんなことよりBazaarしようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ∥ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
284:デフォルトの名無しさん
11/10/10 14:25:09.84
結局、gitを使うと、svnで培ったオレ流を他の奴が守ってくれないかも
しれないから嫌だ。っていう文句しか言ってないのね。
どうせsvn使ったってオレ流を人に押しつけてるだけだから
うまくいかないのに、それをDVCSのせいにされてもねぇ。
svnでできることはgitでもできる。
gitでは他の便利なことや柔軟な運用もできる。
それでも最終的な成果物のコミットのポリシーをどうするかは
属人的な問題で人と人の意思の疎通でしか解決できない。
VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ
いずれプロジェクトは滅茶苦茶になるさ。
それはDVCSのせいじゃない。
285:デフォルトの名無しさん
11/10/10 14:25:19.69
富士通ではVCSすら使ってなかったなあ
大きなプロジェクトはPerforce使ってたけど
git使ったら他には戻れないと個人的に思うなあ
286:デフォルトの名無しさん
11/10/10 14:27:08.02
ちょっと履歴を遡りたいときにはgit reset HEAD^^よりもgit commit HEAD^^の方がいいかな？
287:デフォルトの名無しさん
11/10/10 14:27:49.60
煽ってんじゃねえよてめえ
288:デフォルトの名無しさん
11/10/10 14:34:20.57
>>286
git checkoutだろ
289:デフォルトの名無しさん
11/10/10 14:36:12.50
そうだった。checkout
290:デフォルトの名無しさん
11/10/10 17:35:25.24
ギットギトのgit
291:デフォルトの名無しさん
11/10/10 19:06:37.78
>>256
よく分からんが今の状態を取りやめたいなら
git reset
でいいんじゃね？
292:デフォルトの名無しさん
11/10/10 19:21:26.54
ポインタにNULLを入れて
何回でもギットギトにしてやる
293:241
11/10/11 09:24:33.37
もしかして俺が煽られてるのかなw
>>284
>svnでできることはgitでもできる。
>gitでは他の便利なことや柔軟な運用もできる。
>それでも最終的な成果物のコミットのポリシーをどうするかは
>属人的な問題で人と人の意思の疎通でしか解決できない。
だからそのポリシーをどうすればsvnを使ってるチームが移行しやすいか、
という話なんだが。
運用上svnから劣化する点があれば対策を考えるよね。
運用ルールでなんとかできるのか、どうしようもないのか。
自由度が高いならなおさら「gitにしました。あとは好きにしろ」じゃ
回らないよね
>VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ
svn使ってたらsvn利用を前提にプロセスを最適化するのは当然だろ
294:デフォルトの名無しさん
11/10/11 09:28:46.16
>>293
> 運用上svnから劣化する点があれば対策を考えるよね。
？？？？？？？？？？？？
295:デフォルトの名無しさん
11/10/11 10:19:13.55
とりあえずオープンソースで今時svn使ってるプロジェクトはうんこ
パッチ書いて送ったら「tortoise diffじゃないとヤダヤダ」とかぬかすような連中ばっかり
296:デフォルトの名無しさん
11/10/11 10:21:50.23
パッチとか面倒なこと考えずに直接更新すればいいだろ
297:284
11/10/11 12:50:03.08
>>293
あなたを煽ったつもりはないです。
自分のプロジェクトはsvnが合ってるからsvnを使うよというだけの人を
どうこういうつもりはまったくないので。
VCS使わないって選択肢もありだと考えますし。
ただ、そのことをもって、
gitそのものをdisるキチガイが湧いていたので、
それに反論したのみです。
298:デフォルトの名無しさん
11/10/11 12:52:01.85
gitは無駄に２重管理する生産性の低いうんこだし
git使って開発してるやつはもっとうんこです
299:デフォルトの名無しさん
11/10/11 12:59:21.60
２重管理厨しつこい
300:デフォルトの名無しさん
11/10/11 13:01:49.61
かかってこいよ
301:デフォルトの名無しさん
11/10/11 13:04:10.15
何をやりたいのか分からないな。
svnを褒め称えてgitをdisればみんながgitを放棄してsvnへ流れてくれるとでも思っているのだろうか。
302:デフォルトの名無しさん
11/10/11 13:43:29.39
２重管理地獄の中で悶えて死ね！！！
303:デフォルトの名無しさん
11/10/11 17:40:00.81
2重管理したくないやつは、しなきゃいいんじゃね？
304:デフォルトの名無しさん
11/10/11 17:50:07.41
何が２重管理なのか理解できないのだが
305:デフォルトの名無しさん
11/10/11 19:31:02.34
2重管理って何?
306:デフォルトの名無しさん
11/10/11 19:41:48.17
派遣先用と自社用に２枚勤務管理表を書かないといけないだろ？
307:デフォルトの名無しさん
11/10/11 20:07:51.85
>>293
svnでの運用ルールが破綻してgitに乗り換えようとしたが
gitが難解でgitに八つ当たりしているのですね？
308:デフォルトの名無しさん
11/10/11 20:35:54.93
二重管理最高だろ。
svnのコミットするのに申請書が必要な環境では
ローカルリポジトリと共有フォルダ内work内のbareリポジトリで
実質的な管理をするもんなんだよ
309:デフォルトの名無しさん
11/10/11 20:56:01.10
２重管理求められる環境とか経験ないんだけど申請書？とか必要ない環境だったら２重管理のメリットなんか何もないってことだよね？
２重管理とかマージするときに競合が起きた場合の面倒臭さがより増大するだけじゃないの
310:デフォルトの名無しさん
11/10/11 21:00:21.90
なるほど、svnのマージを使ったことが無かったのか
311:デフォルトの名無しさん
11/10/11 21:04:23.49
むしろsvnしか使った事が無いから、必要以上に競合を恐れてるのでは？
312:デフォルトの名無しさん
11/10/11 21:49:49.44
マスターリポジトリと各開発者のローカルファイルがリアルタイムで同期していない以上、
svnもgitも多重管理していることに違いは無いと思うけど。その言い方を真似ると。
その上で、君はsvnでは多重管理している意識が無いと言っているわけだけど
同様にgit使ってる人も多重管理してる意識は無いよ。
ローカルコミットは自分の完全支配下にあるブランチ、とでも考えれば理解しやすい？
(あ、svnでブランチ切るのも多重管理だね。trunkしか使ってないってことはないよね？)
svnだと開発者の誰もが好き勝手ブランチ切ったりできないでしょ。不便じゃない？
313:デフォルトの名無しさん
11/10/11 21:49:55.07
使ったこと無いのに批判してるように見えるなあ
とりあえず社内がsvn使っててもローカルフォルダだけgitで運用する事もできるし
挫折しないで一通り試してみ
314:デフォルトの名無しさん
11/10/11 22:34:11.38
Linux開発向けに大人数でバザール的に作業すること目指してるのが
社内数人のチームで完全に設計してから実装するみたいな用途には
オーバーエンジニアリングに感じるのかも。
パッチ書こうとしてるOSSのリポジトリがsvnだとがっかりするけど
職場のリポジトリがsvnでも若干の不便しか感じない。
315:デフォルトの名無しさん
11/10/11 23:28:41.20
svn もまともに使えないのに git は無理だろう
と、思うことはある
バージョン管理は二の次だったりする所もあるからなあ
レベルは決して低くない所だが
316:284
11/10/11 23:49:37.35
>>293 はまともなsvn使いがgitへの移行を検討するに当たって
gitの実運用上の問題を挙げてるにすぎないんだから、
これ以上煽ってやるな、真面目っぽいからかわいそうだ。
317:デフォルトの名無しさん
11/10/12 00:04:26.67
いや、svnのコンフリクトを防ぐために運用ルールを定めているのであれば、それはツールに使われている。
欠陥ツールであるsvnを破棄してgitに移行すべきであろう。
318:デフォルトの名無しさん
11/10/12 00:05:01.21
俺には>>298とか>>309への反論に見えるな
素人考えでもマージするときの面倒さはsvnもgitも変わらないように思えるんだが
319:デフォルトの名無しさん
11/10/12 00:41:17.03
マージ作業自体の手間はかかるにしても一旦コミットしてからマージできるから
リモートにブランチつくったりローカルの変更を手で保存したりしなくても
変更が失われないってのは結構な利点じゃない？
320:デフォルトの名無しさん
11/10/12 08:00:56.75
gitはTortoiseGitとmsysgitの２重管理のうんこ
321:デフォルトの名無しさん
11/10/12 08:33:09.15
tortoisegit がうんこだったのは同意。ログ見るときと日本語で commit message 書くときくらいしか使ってなかった。
入れ替えるモチベーションなくしてんだが、最近のはどーなんだろ?
もう msysgit のコマンドラインで十分になっちゃってるしなー。
ところでロック厨がわいてくるだろうと蒸し返すw
322:デフォルトの名無しさん
11/10/12 08:54:23.81
>>320
2重管理という用語を使ってる君自身がその用語をちゃんと定義しきれていない気がするよ。
もうちょっと正確に言ってもらわないと、君が疑問に思っていることがあっても残念ながら中々答えてあげられない。
323:デフォルトの名無しさん
11/10/12 09:05:20.36
意味もわからない覚え立ての言葉を使いたい小学生なんだろ
324:デフォルトの名無しさん
11/10/12 09:26:45.65
すぐうんこ言うしな
325:デフォルトの名無しさん
11/10/12 11:13:59.02
ローカルにコミットするメリットがさっぱり分からん
326:デフォルトの名無しさん
11/10/12 11:20:47.64
>>325
ここgitのスレだからそういう一般的な話はこっちで聞いた方が良いよ。
バージョン管理システムについて語るスレ8
ｽﾚﾘﾝｸ(tech板)
327:デフォルトの名無しさん
11/10/12 11:51:08.17
いやローカルにコミットできることを分散型だと言ってgitの長所だと主張してんだろ？
そこは納得いく説明をしてくれないと
328:デフォルトの名無しさん
11/10/12 11:53:58.13
回線が切れてても大丈夫。
履歴を好き勝手編集しても大丈夫。
パスワードなどの個人情報を入れた状態でcomitするなどの事故を減らせる。
329:デフォルトの名無しさん
11/10/12 13:15:20.42
ローカルコミットの何が嬉しいの？って言う時点で分散型を
必要としてないよ。どうせマンドクセーってぎゃーぎゃー言うだけ。
330:デフォルトの名無しさん
11/10/12 13:20:25.71
回線が切れてても中央のリポジトリから最新版を取ってきたりコミットできるの
履歴を簡単に書き換えられて過去のある版を取り出したくなったときとか困らないの
事故を減らせる代わりに面倒臭くなってるよね
331:デフォルトの名無しさん
11/10/12 14:03:05.74
>>327
gitだけの特徴じゃないんだよ。
332:デフォルトの名無しさん
11/10/12 14:03:16.03
>>330
履歴の書き換えはローカルだけだから無問題
タグが何のためにあるのか考えよう
タグを見るためにいちいちsvn listコマンドなどを叩いてリモートに見に行く方ががよっぽど面倒
333:デフォルトの名無しさん
11/10/12 14:07:09.37
>>331
svk
334:デフォルトの名無しさん
11/10/12 14:32:19.88
回線が切れてたらさすがにリモートの最新版は取ってこれないが、log,diff,(ローカルに現存してるコミット間での)mergeなんかは使える
というかリモートリポジトリを必要とするpull/push以外の全機能が使えるしそういうコマンドはもともと通信しない
335:デフォルトの名無しさん
11/10/12 14:40:32.34
リモートを書き換えないなら何もしてないのと一緒じゃん
ローカルのものをいきなり成果物として客にリリースしたりするの
336:デフォルトの名無しさん
11/10/12 14:43:33.10
プログラミングにおいて一切の試行錯誤をしないのか？
ああ、与えられた仕様書をコードに起こすだけのコーダなのか
gitはそういうコーダのためのツールじゃないから
337:デフォルトの名無しさん
11/10/12 14:45:06.48
回線切れてるならsvnだろうがgitだろうが手旗信号でも使わないかぎりリモートと通信できるはずないだろｗ
338:デフォルトの名無しさん
11/10/12 14:46:05.37
ローカルでコミットなんかしなくても試行錯誤はできるだろ
339:デフォルトの名無しさん
11/10/12 14:48:00.16
試行錯誤をどうやって管理すんの？
log見たり複数の試行錯誤のdiffとったりmergeしたりせんの？
340:デフォルトの名無しさん
11/10/12 14:54:22.27
中央にコミットするまでのあるまとまった単位の修正だろ？
そんなもん#if 0 #else #endif とかコメントで十分だろ
341:デフォルトの名無しさん
11/10/12 14:57:03.11
え？svn使いってそんなことしてんの？いまどき？
それで十分ならマスターリポジトリもそうやって管理したら？
342:デフォルトの名無しさん
11/10/12 15:00:17.54
ローカルな試行錯誤を小刻みにコミットしながらできるのは便利だよ。
そして、その試行錯誤を1～複数のコミットに整理してから、管理されているリモートにpullしてやればいい。
管理されるのは、ごちゃごちゃな試行錯誤より、整理された試行錯誤のほうがいいよ。
343:デフォルトの名無しさん
11/10/12 15:00:29.63
実際それでうまくいってるし２重管理の必要性を感じない
マージするより#if #else でパッと見で分かる方が早いじゃん
344:デフォルトの名無しさん
11/10/12 15:05:21.76
Gitは漠然とした仕様の中手探りで開発するときに向いている。
自分でソフトウェアやプラグインを作るときは仕様の変更や試験的な実装がしょっちゅうあるだろ。
345:デフォルトの名無しさん
11/10/12 15:12:12.23
>>335
回線のつながってない客先にどうやって納品するの？
まさかzip？
それで客先で改変してカオスになるわけだ。
346:デフォルトの名無しさん
11/10/12 15:15:33.01
いつまで小学生構ってるんだよ・・・
347:デフォルトの名無しさん
11/10/12 15:16:49.69
>>337
bundle
348:デフォルトの名無しさん
11/10/12 15:19:01.27
>>346
ここはまんこスレだから
349:デフォルトの名無しさん
11/10/12 15:35:31.42
うんこすれですよ
350:デフォルトの名無しさん
11/10/12 15:36:58.20
>>335当たり前のことだが、リモートに全く接続しないわけでなく、リモートに接続する頻度が減るだけだからな。
351:デフォルトの名無しさん
11/10/12 15:38:50.88
じゃあお前ら#if #elseで処理を有効/無効化したりコメント化したりせずに
わざわざ現状をローカルコミットして処理を消して書き直したりしてんの？
コードに残しときゃすぐ分かるのにバカじゃね
352:デフォルトの名無しさん
11/10/12 15:48:55.65
>>351
Linuxカーネルでは#ifは禁止。
コミットログに書いて十分なものを、コメントに書くのは馬鹿。
コメントはメンテされていないことがほとんど。信用できない。
353:デフォルトの名無しさん
11/10/12 15:56:09.42
別にLinuxカーネル作ってるわけじゃねーしｗ
ローカルコミットの内容だって信用できないものなのに大事に保管しとく意味ねーだろ
354:デフォルトの名無しさん
11/10/12 15:59:07.30
>>353
svnのコミットは信用できるのか？
355:デフォルトの名無しさん
11/10/12 16:21:18.26
もはやVCSそのものを否定してるレベルだな
なんでsvn使ってるんだ？
356: 忍法帖【Lv=40,xxxPT】
11/10/12 16:24:46.00
>>351
そんな意味のないプリプロセッサ付けんな! ソースが汚くなって見辛いし、ほんとに大事なものが見えなくなる。
357:デフォルトの名無しさん
11/10/12 16:31:32.11
>>351
ファイルが無駄にでかくなるし、そもそも修正履歴が追えないだろ
358:デフォルトの名無しさん
11/10/12 17:09:35.70
>>355
うんこなソースの肥溜め
359:デフォルトの名無しさん
11/10/12 17:40:10.63
#if がどっさりうまったうんこコードを書く小学生がいるスレはここですか？
360:デフォルトの名無しさん
11/10/12 18:28:06.34
試行錯誤の段階の話だろうが
最後は綺麗にしてコミットするに決まってるだろ
日本語もまともに読めないカスどもが２重管理地獄で悶絶して市ね
361:デフォルトの名無しさん
11/10/12 18:33:01.30
>>360
試行錯誤でも#if使うのはうんこ
362:デフォルトの名無しさん
11/10/12 18:35:38.48
>>360
その「最後は綺麗にしてコミット」するのが圧倒的に楽なのよ。
Gitで>>342のやり方をすれば。
363:デフォルトの名無しさん
11/10/12 19:08:45.38
ブランチの概念を教えたほうがいいかもしれない
364:デフォルトの名無しさん
11/10/12 20:01:29.80
どんだけ大規模な試行錯誤してんの？
#if #else自体もほとんど使う機会ないんだけど
ローカルでそんな大規模な修正してて中央にコミットするときに競合した場合に
ものすごく面倒臭いんじゃないの？競合相手も大規模な試行錯誤してんだろう？
365:デフォルトの名無しさん
11/10/12 20:07:09.87
試行錯誤がフィーチャーブランチだったら公開した方がみんなのためだろう
svnはブランチがうんこだからできないけど
366:デフォルトの名無しさん
11/10/12 20:18:54.24
コーディング規約で過去コードをコメントや#ifで残すようにとか決まってるんじゃないの？
そういう時にはチーム内管理用のコードと正式コミット用のコードをブランチで分けるんだよ
で、邪魔なコメント過去コードは正式コミット用コードにだけ残しておいて、
プロジェクトリーダーが週例前に内部用コードとマージして一括してコミットする。
367:デフォルトの名無しさん
11/10/12 20:32:11.21
ただ宗教戦争したいだけのヤツなんだからもういいかげん相手にするなよ・・・
368:デフォルトの名無しさん
11/10/12 20:44:01.79
>>367
神聖なまんこスレからうんこは排除せねばならない
369:デフォルトの名無しさん
11/10/12 20:55:48.66
>>364
数行の修正×数箇所とか程度の簡単な修正でもGit使うと楽よ。
エディタでソース修正してローカルなコミットを作った後は、
動作確認して必要なコミットだけをまとめてコメント付け直してリモートに登録するとかを
コマンド叩くだけでできるし。
#if#elseとかでやる場合は最後もエディタでソースを整形しなおすんでしょ？
その段階で修正間違えたりしたら目も当てられない。
370:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/12 22:05:14.52
機能A追加、機能Aを使う機能B追加、機能Bを使う機能C追加
のような3つのコミットをしたい時に、機能Cを作りながら機能A、Bもデバッグ
して、きれいにして、最後に3つに分けるんだけど、後から分割するのって大変
なんだよね。そういうのは、gitやhgだとコミットを行ったり来たりしながら作
業できて便利。だから例えsvnでやれと言われても、手元でgitとか使っちゃう
と思う。
372:デフォルトの名無しさん
11/10/12 22:42:05.11
>>343
よかったな。リリースされたSVN1.7.0でも2重管理とやらの機能が強化されたぞ。
URLﾘﾝｸ(subversion.jp)
373:デフォルトの名無しさん
11/10/13 01:22:56.98
GitHub のデザイン変わった？
374:デフォルトの名無しさん
11/10/13 11:37:34.43
gitはPerforceが高くて買えない貧乏人に最適
むしろgitの方が優れてるし
つまり、全人類にとっての光明
375:デフォルトの名無しさん
11/10/13 12:40:01.95
今度は買い物P4厨を呼び込むための撒き餌か!?
宗教戦争とか政治論争は別のスレでやろうや。
376:デフォルトの名無しさん
11/10/13 16:54:08.89
git 1.7.7 の msys版がでたけど、
msysGit-fullinstall-1.7.7-preview20111012.exe からだと
生成されるファイルのサイズが全然違うのはなんでだろうか。
--version の表示結果からして違うせいなのか、
デバッグ用の実行ファイルになってるのかな
377:デフォルトの名無しさん
11/10/13 19:55:32.92
>>372
それは誤読もいいところ。
そこに書いてあって1.7で実現されたgit的なものは
.svnがひとつになったことぐらい。
これは無条件に良くなったと言える。
378:デフォルトの名無しさん
11/10/13 19:59:36.91
じゃあ相変わらず #if 使う日々が待ってんのか
大変だな
379:デフォルトの名無しさん
11/10/13 21:26:01.98
1.7のリリースまでにはまとめられなかっただけだろ。
2重管理とやらをしてないのに。
380:デフォルトの名無しさん
11/10/13 21:29:40.03
2重管理地獄の中で悶えて死ね
381:デフォルトの名無しさん
11/10/13 23:56:21.07
Git使ってると気持ち良くて悶えちゃう
382:デフォルトの名無しさん
11/10/13 23:58:52.37
>>380
お前もローカルでは #if で手動管理してるんだろ？
まあ管理と呼ぶのもおこがましいが
383:デフォルトの名無しさん
11/10/14 02:20:43.90
流れ読まずに横から質問…。
ローカルに好き勝手なタイミングでコミットしまくって出来上がった、うまく言語化できない成果物があるとして
それをいわゆる中央リポジトリにキレイな履歴で送りつけたいとき、
みんなは具体的にはどうやって整理してるの？
もしやsvnとかとは、コミットの粒度がケタ違いに違う？
384:デフォルトの名無しさん
11/10/14 02:47:30.64
>>383
分離すべきと思う単位で分割するかな。つまり機能毎に。
関数追加～とかの単位だと意味が無いし、逆に複数の機能が単一のコミットに入っていると
一部だけ採用できない。
また、ビルドが通らないというのは論外だけど、例えば「新機能1」「新機能1のテストコード」
とかは同じコミットにすべきだし、単体で意味のあるバグ修正なんかは別のブランチに
してマージしたい。俺は。
385:デフォルトの名無しさん
11/10/14 04:30:35.56
公開リポジトリまたは他人のリポジトリには、基本、
「この機能いらないからこのコミットだけ却下」
ということができるようにローカルで調整してコミットしたブランチを送りつける
いやもちろんプロジェクトのポリシー次第なのだが
単一の機能を実現するためにあちこちいじらないといけないときは説明的なコミット満載の単一のブランチにしたりもする
あちらでsqashしてくれるんだろうと思ったらそのままブランチごと適用されてお茶吹いたりもするのであんまり勧めない
386:デフォルトの名無しさん
11/10/14 06:33:17.19
>>379
svn1.7ではクライアントにsqliteを使うことで２重管理を実現しています
URLﾘﾝｸ(subversion.jp)
387:デフォルトの名無しさん
11/10/14 06:35:24.18
>>377
残念ながらsvn1.7ではsvnユーザが行っていた２重管理はできなくなりました。
> **警告**: SQLiteライブラリを通じてSQLiteにアクセスがある間に、SQLiteのファイルをコピーするのは安全ではありません。
> 結果として、 Subversionプロセスからアクセスされているワーキング・コピーの複製を作る事(tar, rsync, cpなどで)は、
> Subversion1.7ではサポートされません。それは壊れている可能性があります。(課題 #3596)
388:デフォルトの名無しさん
11/10/14 06:39:26.99
>>383
最終的には科学的な指標なんてなくて、美的センスの問題。
383の改行が、いうなれば、パッチ整理のようなもの。
１改行は、それぞれが強く関連する、小さな意味単位としての分割。
２改行は、それらのグループ間での分割。
パッチの分割も３８３の文章と同じ要領。結局これは、最後は美的センスの問題になる。
機械的で具体的な数字には示し難い。
389:デフォルトの名無しさん
11/10/14 07:10:39.64
>>386-387
いいかげんウザい
馬鹿に付き合ってるお前も馬鹿に見えてるのに気付け
390:デフォルトの名無しさん
11/10/14 07:49:10.23
今時VCSにSQLiteを使うのは馬鹿だな
391:デフォルトの名無しさん
11/10/14 10:41:29.00
>>390
どうちて？
392:デフォルトの名無しさん
11/10/14 11:11:53.08
>>391
SQLiteはロック前提だから。
そんなことも分からないsvn開発者は馬鹿。
393:デフォルトの名無しさん
11/10/14 11:21:55.97
ありがとう。ちょうどsvnスレでその話挙がってるね。スレ違いすまんこ。
394:デフォルトの名無しさん
11/10/14 12:19:33.60
きにすんなちんこ
395:デフォルトの名無しさん
11/10/14 16:17:42.57
BerkeleyDB依存からは脱却できたのに…
396:デフォルトの名無しさん
11/10/15 08:09:23.33
なにか要求をシリアライズしているプロセスをかませばいいのに
それこそhttpdの何かとか
397:デフォルトの名無しさん
11/10/15 15:27:30.20
gitの中にはファイルの所有者の情報を保存できないのでしょうか？
chownしてdiffしても何も変わっていないと言われてしまいます
398:デフォルトの名無しさん
11/10/15 16:20:05.56
>>397
できないよ。実行可能かどうかだけ。あとシンボリックリンクはだいじょうぶ。
399:デフォルトの名無しさん
11/10/15 17:39:52.35
>>398
そうなのですか
ありがとうございました
400:デフォルトの名無しさん
11/10/16 14:01:25.77
Git ってたまたまハッシュ値が衝突しちゃった場合ってどうするようになってるの？
401:デフォルトの名無しさん
11/10/16 14:14:39.39
どうもしない
402:デフォルトの名無しさん
11/10/16 14:25:10.57
>>400
前スレの最初の方でやった
403:デフォルトの名無しさん
11/10/16 15:02:17.72
変な動作でエラーになると思われる
（やろうとした処理にもよるが、無言で上書きされて続行されるようなことにはならない、はず）
まあ、エラーになったならそのとき手で修正すればいい
天文学的確率のさらに上をいく事象に事前対処することはリソースの関係上できね
あと、これも前スレで言われてるが、ハッシュに日付とかユーザー名とかくっつけるのは衝突回避確率を強化しない
404:デフォルトの名無しさん
11/10/16 15:21:17.02
URLﾘﾝｸ(progit.org)
> すでにリポジトリに存在するオブジェクトと同じ SHA-1 値を持つオブジェクトをコミットしてした場合、
> Git はすでにそのオブジェクトがデータベースに格納されているものと判断します。
> そのオブジェクトを後からどこかで取得しようとすると、
> 常に最初のオブジェクトのデータが手元にやってきます
> (訳注: つまり、後からコミットした内容は存在しないことになってしまう)。
まったく調べずに嘘を書くのはどうかと
405:デフォルトの名無しさん
11/10/16 19:19:53.77
おまえみたいに調べて訂正してくれるやつがいるから
ある意味 問題ないな
406:デフォルトの名無しさん
11/10/16 19:24:16.94
俺の間違い push も訂正してほしい
407:デフォルトの名無しさん
11/10/16 20:36:16.79
うん？コミット時にはエラーでなくてあとで困るってこと？
それってまずくね
408:デフォルトの名無しさん
11/10/16 20:40:22.26
その前にオオカミの心配しろよ
409:デフォルトの名無しさん
11/10/17 09:12:15.64
SHA1ハッシュが衝突したとしてもオブジェクトの種類が違ったら
たぶんエラーになるから、さらに確率は下がるかな。
410:デフォルトの名無しさん
11/10/17 13:16:40.23
悪意を持って衝突させる奴が出たらそんなこと言ってられない
411:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/17 13:22:40.31
anonymousでpushできる世界の話？
413:デフォルトの名無しさん
11/10/17 13:30:07.71
2重管理で悶えてるじゃねーかｗ
414:デフォルトの名無しさん
11/10/17 18:39:45.51
>>322
415:デフォルトの名無しさん
11/10/17 22:43:50.41
二重管理ってgit-svnのことだったのかよｗ
416:デフォルトの名無しさん
11/10/17 22:46:10.96
>>413
無駄だ
417:デフォルトの名無しさん
11/10/17 23:54:08.81
>>410
意図的にSHA-１を衝突させるとか何者？
418:デフォルトの名無しさん
11/10/18 00:00:29.53
>>410
できないできない絶対できない
やれない気持ちの問題じゃない
419:デフォルトの名無しさん
11/10/18 00:02:40.58
できるできる絶対できる！
420:デフォルトの名無しさん
11/10/18 00:11:19.82
たとえ将来、自由にハッシュを衝突させることができるようになったとしても
既存のリポジトリの内容を破壊できるわけでもなんでもないその行為になんの意味があるの？
421:デフォルトの名無しさん
11/10/18 00:19:18.86
// コメントを外すと何故かコミットできない
422:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/18 06:14:39.87
>>411
俺はmerge時には--no-ffしてる。
424:デフォルトの名無しさん
11/10/18 08:05:41.70
411です。
ありがとうございました。
今日もういちど
しらべたりやってみたりしようと思います。
425:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/18 12:48:01.10
2重管理地獄の中で悶えて死ねｗ
427:デフォルトの名無しさん
11/10/18 13:09:33.26
>>322
428:デフォルトの名無しさん
11/10/18 13:15:06.14
>>425
addしていないファイルはどのブランチにも属さない
単に管理されていないから、どのブランチにいても「未管理ファイル」として表示される
それだけ
429:デフォルトの名無しさん
11/10/18 13:18:41.03
あー、なんとなくわかってきました。
testのほうでadd/commitするとtestが新しくなり、
masterに切り替えると古い版が維持されてました。
最初からやりなおしてまたtestで修正し、今度はmasterに切り替えてこっちで
add/commitすると、masterが新しくなり、testのほうが古いmasterの状態を
維持してました。
こういうものなんですね。co すると、そのブランチの
（こっちが期待している元の）状態に全部きれいに切り替えてくれるものと
思ってましたし、ブランチでの修正をmasterでcommitできるとか
考えてもみませんでした。
たぶん私は「ブランチ」の概念から理解しなおさないとダメですね。
430:デフォルトの名無しさん
11/10/18 19:23:36.94
ブランチというか、ステージングの概念じゃない？
ワークツリーの変更を退避したければ git stash でできるよ
でも、とりあえずコミットしておいてあとでコミットを編集・整理するのでも良いと思う
431:デフォルトの名無しさん
11/10/18 19:25:39.62
概念がどうとかいうほどのもんかね？
432:デフォルトの名無しさん
11/10/18 19:26:24.02
gitってうんこだな
433:デフォルトの名無しさん
11/10/18 19:32:13.07
>>431
いやだってbranchとは別物じゃない
434:デフォルトの名無しさん
11/10/18 19:58:28.05
gitはbranchとstashの2重管理のうんこ
435:デフォルトの名無しさん
11/10/18 22:49:25.35
あれからあらためてman読んだり自分で考えたりして、それなりにわかりました。
gitにはようするに「コミットオブジェクト」みたいなものしかないわけですよね。
タグはもちろんブランチも、ユーザのための記号みたいなもの。
だからブランチをつくったばかりなら、両ブランチは対等というかおんなじもので、
どちらが親とか、そういう意味もない。コミットした時点で初めて、
新たな「コミットオブジェクト」がつくられる。
あるコミットオブジェクトがどのオブジェクトから派生したか、といった情報は、
オブジェクトがつくられるときに記録される。
こう考えるとすごくわかりやすくなりましたし、シンプルでいいな、と思いました。
こんな感じに理解しましたが、だいたい合ってますでしょうか？
436:デフォルトの名無しさん
11/10/18 23:35:29.83
だいたい合ってる
しいていえばタグは特定のコミットをピンポイントで指すけど、ブランチはコミットの歴史（HEADの変遷）を指すってところかな
437:デフォルトの名無しさん
11/10/19 00:03:29.96
Git のタグは、軽量 (lightweight) 版と注釈付き (annotated) 版の2重管理のうんこ
438:デフォルトの名無しさん
11/10/19 00:30:05.82
バージョン管理システム界にカオスと混乱を招いたgitの罪は重い
439:デフォルトの名無しさん
11/10/19 00:45:54.69
>>436
ありがとうございます。
タグとブランチの違いについても考えてましたけど、おおむね間違ってなかったみたいです。
使いかたはまだまだ練習中ですが、いろいろわかってきたので面白いです。
440:デフォルトの名無しさん
11/10/19 08:05:53.27
gitを理解できない奴の頭の中がカオスになってるだけだろ。
自分の頭の悪さを罪だと思えｗ
441:デフォルトの名無しさん
11/10/19 08:30:20.91
構うなベアード
442:デフォルトの名無しさん
11/10/19 08:58:52.72
>>435
シンプルでいいよね。そこに気づけばもう迷うことはないよ。
必要に応じてコマンド覚えていけばいいだけ。おめでとう。
443:デフォルトの名無しさん
11/10/19 15:48:27.96
今一番使われているバージョン管理システムってgitなんすか
444:デフォルトの名無しさん
11/10/19 16:07:14.60
ちょっと調べてみて使い方がスっと入ってこない時点でうんこ
445:デフォルトの名無しさん
11/10/19 19:43:26.24
>>443
今一番使われてるのはSubversion
オープンソース開発でGitが増えている
一般の開発でもGitが増えつつある。
svn→gitは便利になることもある反面失うものも多いから
単純に置き換えが進むというものではなくてずっと共存すると思う。
過去、cvs→svnはなにも失うものが無かったから一気に移行が進んだ
446:デフォルトの名無しさん
11/10/19 20:05:51.00
失うものがないもっと良いやつ作れよ
何が分散型だよ中央とローカルで２つsvnリポジトリ持ってるのと一緒じゃねーかｗ
447:デフォルトの名無しさん
11/10/19 20:08:14.93
失うもの "SVN厨"
448:デフォルトの名無しさん
11/10/19 20:14:24.67
何かを得れば何かを失う。人生とはそんなものだ。
状況に応じて使うか使わないかを決めるといい。
449:デフォルトの名無しさん
11/10/19 20:14:40.98
失うもの
・コミッタの特権
・リビジョン番号
・svn的なタグ・ブランチ
450:デフォルトの名無しさん
11/10/19 20:22:17.82
Linusも開発してて途中でうんこだと気付いたから手を引いたんだろうな
451:デフォルトの名無しさん
11/10/19 20:45:32.75
使えないとか言ってるやつはとりあえずこれ読んでこの通りブランチ運用してみろ
A successful Git branching model(翻訳)
URLﾘﾝｸ(keijinsonyaban.blogspot.com)
ある程度やったらGit log --graph --statってやってみ
こりゃ便利だと思うぞ
452:デフォルトの名無しさん
11/10/19 20:47:39.83
で、あのおっさんがうんこと気づかずにメンテナ面して得意満面にいじくりまわしてるってか?
…ちがうだろ、基本設計が良かったから発展し続けてるんだろ?
俺は単にJunioのことをおっさん呼ばわりしたかっただけだw
453:デフォルトの名無しさん
11/10/19 20:54:26.03
>>451
グラフがうんこになるのを推奨している記事か
454:デフォルトの名無しさん
11/10/19 20:55:34.40
うんこを押し付けられてせっせとメンテナンスするおっさん…
455:デフォルトの名無しさん
11/10/19 20:59:19.29
svnみたいなうんこツール使ってると性格までうんこになるのか
456:デフォルトの名無しさん
11/10/19 21:00:32.44
gitは中途半端でめんどくさいツールでＦＡ
たぶん3年後くらいにちゃんとした次世代バージョン管理システムができるから
それまでsvnでいいや
457:デフォルトの名無しさん
11/10/19 21:03:15.06
>>456のほざく「次世代」に「SVNと同様の」が多分に含まれてる汚感。
458:デフォルトの名無しさん
11/10/19 21:09:17.58
>>457
つBazaar
459:デフォルトの名無しさん
11/10/19 21:26:06.35
うんこ話は盛り上がるがまんこの方が好き
盛りまん
460:デフォルトの名無しさん
11/10/19 22:03:50.73
>>446
Mercurialならgitより失うものは少ないんじゃね
461:デフォルトの名無しさん
11/10/19 22:15:51.61
git log --name-status -M
とかやると移動の履歴も見れて素敵なんだけど
ファイルステータスの記号に続く3桁の数字の意味ってなんなんだろう。
R077 R100 とか、合致率とかかな？
462:デフォルトの名無しさん
11/10/19 23:41:34.07
>>449
＞・コミッタの特権
これかなりメインテーマだよな。
>>461
多分そうだろうなーと俺も思ってた。
463:デフォルトの名無しさん
11/10/19 23:57:55.46
TortoiseGitのFormat patchで作ったパッチ、何でファイル名の前に
a/とかb/がつくの？付けさせない方法ないの？
464:デフォルトの名無しさん
11/10/19 23:59:34.28
番号飛びすぎﾜﾛﾀwwww
まだ一所懸命やってるようだな。ご苦労なことだ。
465:デフォルトの名無しさん
11/10/20 06:47:53.91
>>463
diff.noprefix のことだとは思うが後悔するなよ? tgit で試してないから知らん。
466:デフォルトの名無しさん
11/10/20 12:17:02.67
>>446
良いよ。いくら払う？
467:デフォルトの名無しさん
11/10/20 12:44:32.82
>>446
svkのこと？
468:デフォルトの名無しさん
11/10/20 13:03:19.48
かかってこいよ
469:デフォルトの名無しさん
11/10/20 18:56:12.46
さっさとかかってこいよブタ共
470:デフォルトの名無しさん
11/10/20 19:13:18.48
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ そんなことよりBazaarしようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ∥ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
471:デフォルトの名無しさん
11/10/21 08:14:27.43
gitで管理しているディレクトリの配下に、
他のリポジトリからディレクトリをcloneしたりしたら問題になりますか？
472:デフォルトの名無しさん
11/10/21 08:51:50.02
>>471
addしなけりゃいいだけだ。
してもgit的には問題は無いけどまあ普通しないわな。
473:デフォルトの名無しさん
11/10/21 09:46:45.30
>>471
submodule使おう
474:デフォルトの名無しさん
11/10/21 12:52:54.39
--reference (objects/info/alternates) に含まれているオブジェクト以外を prune することってできる?
もちろん alternates の先はオブジェクトが消滅せずひたすら追加されていく前提で。
475:デフォルトの名無しさん
11/10/21 12:53:50.02
>>474 うわ日本語間違えた。
「alternates が保持しているオブジェクトをローカルオブジェクトから prune」だ。
476:デフォルトの名無しさん
11/10/21 23:01:08.48
Bazaarスレ、なんか埋め立てられているし
477:デフォルトの名無しさん
11/10/21 23:06:37.77
分散型バージョン管理システムとは３ＤＳみたいなもの
478:デフォルトの名無しさん
11/10/22 00:34:59.24
cvs:ゲームボーイ
svn:DS
git:3DS
479:デフォルトの名無しさん
11/10/22 02:03:17.54
cvs:ゲームボーイ
svn:ゲームボーイカラー
git:DS
480:デフォルトの名無しさん
11/10/22 06:33:19.13
cvs:ファミコン
svn:スーファミ
git:バーチャルボーイ
481:デフォルトの名無しさん
11/10/22 09:18:25.92
やれやれだ
482:デフォルトの名無しさん
11/10/23 19:28:28.36
サードパーティというかベンダというか、そういう外部由来のソースの小さなバグ直したり、
ちょこっと「自分仕様」を追加したりしつつ利用していくときって、
ブランチはオリジナル版とカスタム版のどっちをmasterにしとくのがいいんでしょう？
オリジナル版の更新も取り込みつつ、カスタム版をメインに利用する、
と考えると、master/vendor っていう分けかたがいいのかな、とは思うんですけど・・・
483:デフォルトの名無しさん
11/10/23 19:54:13.12
どうでもいいよ
pull/pushするときに送信ブランチ名と送信先ブランチ名を指定できる（つまり、送受信時に自由にリネームできる）から、手元では好きに名前をつけるといい
484:デフォルトの名無しさん
11/10/23 20:30:04.96
もっと言うと master というブランチ名自体に特別な意味はない。
一般的には外部由来のもの、すなわち pull 専用のものを origin/master -> master として
自分用ブランチを設けて好き勝手にやるのが自然。
上流(この場合外部)に自分の変更の一部を反映するための方策についてはまた別の話。
485:デフォルトの名無しさん
11/10/23 20:47:15.83
いちおう慣習的なブランチの名前というのはいくつかあったはず
486:482
11/10/23 21:40:50.26
なるほど、これといったルールはないんですね
ただのzipとかtarballでしか配布されてないものなんかも想定しているので、
自分がわかりやすいと思う分けかたでやっていくことにします
487:デフォルトの名無しさん
11/10/26 20:47:17.46
他の開発者との中央へのコミット内容が競合した場合の対応ってgitだとsvnより楽だったりしますか
488:デフォルトの名無しさん
11/10/26 21:27:48.69
つーかSVNが苦行
489:デフォルトの名無しさん
11/10/26 21:35:10.19
うんこよりマシ
490:デフォルトの名無しさん
11/10/26 21:57:09.24
>>487
楽だよ。3wayマージ賢い。
さすがに同じタイミングでがっつり同じ箇所ぶつかったら
手でマージすることになるけど、補助ツール使えばなんとかなる。
491:デフォルトの名無しさん
11/10/26 22:51:45.87
バイナリ込みで数十 GB とかいける?
492:デフォルトの名無しさん
11/10/26 23:39:13.23
いけると思うけどでかいバイナリを頻繁に変更するならちょっときついかもしれない
493:デフォルトの名無しさん
11/10/27 00:37:19.80
target ディレクトリを毎回コミットする奴にはどういえば直るだろうか
494:デフォルトの名無しさん
11/10/27 07:53:31.04
>>493
TortoiseGit 病だな?
495:デフォルトの名無しさん
11/10/27 09:04:05.61
>>493
gitignoreしたらどうなの？
496:デフォルトの名無しさん
11/10/27 17:07:40.40
3wayマージは補助でp4merge使うと、ほとんど手修正しなくていいぞ
497:デフォルトの名無しさん
11/10/27 22:20:26.99
>>495
新規モジュールでやられてしまうので
498:デフォルトの名無しさん
11/10/28 10:27:29.73
開発ブランチ(master)と、リリースブランチ(rel-X.X)とがあって、リリースブランチ（または開発ブランチ）に行ったcommitを、もう一方のブランチにcherry-pickしています。
このとき、両ブランチの間でどのコミットがcherry-pickされていて、どのコミットがされてないかを調べるいい方法はないでしょうか。
499:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/28 11:32:47.15
>>499
よーわからんけど、ローカルの変更がどうでもいいなら全部消してcloneし直せばいいんじゃ？
501:デフォルトの名無しさん
11/10/28 12:46:04.13
>>499
競合のあるbranch上で git reset --hard origin/upstream_worktree
502:デフォルトの名無しさん
11/10/28 13:12:17.86
>>498
git cherry -v branchA branchB
で、ある程度分かるかもしれない
503:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/28 15:39:51.17
また２重管理で苦しんでるな
何の罪も無い純粋な技術者がなぜ苦しまなければならないのか
505:デフォルトの名無しさん
11/10/28 15:49:26.51
別に苦しんでないだろ
自分で調べるのが面倒なのがここで質問して、おせっかい焼きが答えてるだけ
506:デフォルトの名無しさん
11/10/29 13:35:21.20
HEADだけcloneするにはどうやればいいのでしょうか？
507:デフォルトの名無しさん
11/10/29 15:12:07.97
なんだそりゃ
全ファイルの旧編集履歴をひとつの最新コミットに詰め込んで新たに履歴1個だけのブランチを作りたい？
508:デフォルトの名無しさん
11/10/29 15:37:35.49
Signed off by って Linus のオナニー以外に何の意味があるの？
509:デフォルトの名無しさん
11/10/29 15:46:14.22
ユーザー無視の開発者のオナニーの産物
510:デフォルトの名無しさん
11/10/29 20:54:41.26
なんでSigned-off-by:がLinusのオナニーってことになるのか意味不明。
著作権者をtrackするための重要な情報なのに。
511:デフォルトの名無しさん
11/10/29 21:39:58.53
元の作者を尊重しつつ、コード作成とコミットの責任所在をわけることが出来る
仕組みのはずなんだが、Sign-Offに名前が出ることが売名行為に見えてるんだろうね。
512:デフォルトの名無しさん
11/10/29 22:12:58.99
名無しさん以外のものを拒絶する2chならではの反応だなぁ、と
513:デフォルトの名無しさん
11/10/29 22:45:05.74
author と comitter の違いとは別なの？
514:デフォルトの名無しさん
11/10/30 04:12:17.33
>>506
git clone --depth 1
その後出来ることに制限があるのでman見たりググったりしてくれ
515:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/31 21:29:57.34
$ git tag
としたらタグの一覧が出てきますが、そのタグがどのコミットにつけられたのか知るにはどうしたらいいですか。
今は .git/refs/tags のなかを覗いていますが、さすがに別の方法があるはず。
でも git tag -h してもそれらしいオプションはないし。困りました。
518:デフォルトの名無しさん
11/10/31 21:42:56.10
git show タグ名
519:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/31 21:53:51.18
>>518
それはコミットとかのオブジェクトの中身を表示するコマンドですよね。
たしかにコミットIDも表示に含まれてますが、タグ名とコミットIDの一覧が表示できればそれでよくて、ファイルの中身とかは必要ないです。
ちょうど hg tags のように表示されればいいだけなんですけど、難しいでしょうか。
521:デフォルトの名無しさん
11/10/31 22:51:30.70
gitlab 試したヤシいる？
gitorious と比べてどうよ
522:デフォルトの名無しさん
11/10/31 23:09:06.91
>>517
タグだけ列挙する方法は俺も知らんので git-pack-refs して .git/packed-refs をかっさばけw
本末転倒だが git log --format='%H %d'
>>519
.git/packed-refs ができてないかどうかチェキ
523:デフォルトの名無しさん
11/10/31 23:11:24.52
つか、
GITDIR/refs/tags の一蘭をふつうに得る。
GITDIR/packed-refs の中身をかっさばく
べたにやっていいんではないかと。refs/tagsの方が優先な。
524:デフォルトの名無しさん
11/11/01 10:28:11.94
>>517
g log --decorate |grep "[ (]tag: "
じゃダメ？
525:524
11/11/01 10:31:19.82
あ、"g" は "git" ね
自分のalias書いちゃった
526:デフォルトの名無しさん
11/11/01 10:37:26.84
気にするな
俺もalias g=gitしてるｗ
527:デフォルトの名無しさん
11/11/01 10:52:38.06
refs の中覗くのも、
git log --decorate=full |grep "[ (]refs/"
でできるしね
528:デフォルトの名無しさん
11/11/01 11:15:25.18
>>527
これいいな
タグと各ブランチのHEADだけ一覧できる
529:デフォルトの名無しさん
11/11/01 15:56:50.07
貴様ら git-show-ref を忘れてるだろ！！！
530:デフォルトの名無しさん
11/11/01 17:12:34.96
>>529
マジで忘れてたw
つかコマンドとオプション多すぎなくない？
531:デフォルトの名無しさん
11/11/01 17:36:04.12
>>529
-d つけないとタグとコミットの対応わかんないし、どっちにしろ同じコミットでも
全部別々の行になっちゃうから、>>527のほうが俺は見やすいな
532:デフォルトの名無しさん
11/11/01 18:23:18.58
A-B-C
\-D
D の親は B になっているのを
A-B-C
\-D
親を C に変えるのは rebase D で行けるけど
これの逆に親が C だったのを B にするにはどうすればいい？
533:デフォルトの名無しさん
11/11/01 18:52:52.64
>>532
git rebase --onto B C D
534:デフォルトの名無しさん
11/11/01 22:56:08.88
コマンド体系まで二重管理
535:デフォルトの名無しさん
11/11/01 23:03:32.33
二重じゃないよplumbing porcelain cogit stgit tortoisegit
もちろんネタです
536:デフォルトの名無しさん
11/11/01 23:14:15.39
>>531
tagってtag objectのことだったのか。
--dereference で何が困るんだ?
537:デフォルトの名無しさん
11/11/02 14:55:42.99
git diffの結果を、ファイルか変更箇所ごとにマージするにはどうしたらいいんだろうか。
538:デフォルトの名無しさん
11/11/02 20:48:46.59
>>537
ファイルごとにaddしてcommitしてマージすればいいんじゃないの？違う？
539:デフォルトの名無しさん
11/11/02 21:16:28.81
patch当てたあとadd -pかね。
540:デフォルトの名無しさん
11/11/03 07:10:13.88
>>521
コレ読んでここでなんか話題が出てないかと思って来てみたけど
あなたしかレスしていないね
URLﾘﾝｸ(www.moongift.jp)
541:デフォルトの名無しさん
11/11/05 18:24:22.73
Andoridアプリ開発しようと思ってeclipse落としたら
なんか最初からgit入ってるし
いつの間にかgitが主流になってきてるじゃねえか
まじやべえgitこわいよー
542:デフォルトの名無しさん
11/11/05 21:29:13.01
お前も二重管理の苦しみを味わうがよいｗ
543:デフォルトの名無しさん
11/11/05 22:05:47.33
eclipse, egit, jgit, cygwin, msysgit, tortoisegitの６重管理
544:デフォルトの名無しさん
11/11/05 22:10:46.58
ふらふらするな ぎっとしろ。
545:デフォルトの名無しさん
11/11/06 05:23:22.52
gitでも高性能な機能を使わなかったら一重管理できるよね。
俺はブランチも切らずただひたすらcommit -allしてるだけだし。
546:デフォルトの名無しさん
11/11/06 08:59:10.87
高性能な機能と単純な機能の二重管理()笑
547:デフォルトの名無しさん
11/11/06 14:20:27.66
二重管理言いたいだけなんじゃないかと・・・。
548:デフォルトの名無しさん
11/11/06 15:19:13.05
何を今更
549:デフォルトの名無しさん
11/11/06 19:24:51.23
eclipseにデフォルトでcvsとgitは入ってるんだけどsvnは入ってないんだよね
svnってオープンソース界から嫌われてるの？
550:デフォルトの名無しさん
11/11/06 19:30:21.87
svnはコミット権を持つ者が支配層だからね。
そんな時代は終わりにしたいのさ。
551:デフォルトの名無しさん
11/11/07 20:44:28.91
ぎっとなの？じっとなの？
552:デフォルトの名無しさん
11/11/07 20:53:37.61
ぎっと、が一応正しい
「じっとはぶ」と読んでる人が大多数だと思うのだが、あれは「ぎっとはぶ」が正しい
553:デフォルトの名無しさん
11/11/07 21:00:54.00
＞「じっとはぶ」と読んでる人が大多数
それはない
554:デフォルトの名無しさん
11/11/07 21:07:00.25
>>551
URLﾘﾝｸ(ejje.weblio.jp)
555:デフォルトの名無しさん
11/11/07 21:27:45.63
github は、周囲では ぎっはぶ (トが落ちる)が多いなぁ。
全く知らなかったら ぎさぶ (thの発音で)と読んでしまいそう。
556:デフォルトの名無しさん
11/11/07 21:31:13.92
git
音節git 発音記号/git/
【名詞】【可算名詞】
《英俗》 ばか者，ろくでなし.
557:デフォルトの名無しさん
11/11/07 21:49:47.47
じっとだろ
558:デフォルトの名無しさん
11/11/07 21:51:54.91
ギトって読んでるなぁ。GitHubはギトハブって・・・。
559:デフォルトの名無しさん
11/11/07 22:23:23.30
ギットでギットハブの俺にとってはこの流れがカルチャーショックなのだった。
560:デフォルトの名無しさん
11/11/07 22:23:39.37
おまいらもういいから
じっとしてなさい
561:デフォルトの名無しさん
11/11/07 22:37:11.41
git logだと増減したファイルのファイル名や修正されたファイルのファイル名が出ないのですが、
これを見るにはどうすればいいでしょうか？
562:デフォルトの名無しさん
11/11/07 22:42:58.04
git log --name-status かな。
563:デフォルトの名無しさん
11/11/07 23:05:44.39
まずは短めに --stat だな。
564:デフォルトの名無しさん
11/11/08 08:54:59.15
俺はwhatchangedよく使うな
565:デフォルトの名無しさん
11/11/08 10:33:50.10
特定のコミットに存在しないファイルを自動で消す方法ってないですか？
例えば linux kernel で v3.0.8 をコンパイルした後に
git checkout v2.6.32.46
とかした時に、v2.6.32.46に含まれない余分なファイル
を簡単に消す方法が知りたいです。
566:デフォルトの名無しさん
11/11/08 11:25:52.93
>>565
わかんないけど
rm -r *
git checkout v2.6.32.46
とか？
567:デフォルトの名無しさん
11/11/08 11:35:57.00
>>565
git clean -f
でなくて？
568:デフォルトの名無しさん
11/11/08 14:57:35.42
おれは心の中では、ギラハブ
569:デフォルトの名無しさん
11/11/08 15:03:09.65
>>567
うお、それそれ。これが見つかんなくて、>>566 と同じ事してて、
kernel treeだと、3万ファイル以上 checkout するんで
遅くて嫌になってたのよ。
助かったよ、ありがとう。
でも、>>530 じゃないけど、コマンドとオプション多すぎっつか、
逆引き git マニュアルとか欲しいよね。
570:デフォルトの名無しさん
11/11/08 15:13:36.72
ありゃ、ちょっと興奮して言葉遣いが荒くなってしまいました。
>>567の回答で助かりました。ありがとうございます。
571:デフォルトの名無しさん
11/11/08 19:39:46.04
git cheat sheet でぐぐって和訳して首吊って生き返れこんちくしょう
572:デフォルトの名無しさん
11/11/08 19:52:27.14
無罪！
573:デフォルトの名無しさん
11/11/09 07:47:05.98
addで追跡を開始したファイルの追跡をやめるにはどうすればいいでしょう。
ファイルを削除することなしで。
574:デフォルトの名無しさん
11/11/09 07:49:07.55
あ。すいません。すでにcommitされていてindexの中だけでなくリポジトリにも記録されてしまっているファイル
についての話です。
575:デフォルトの名無しさん
11/11/09 08:35:56.81
git rm --cached
576:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/11/09 18:37:44.12
>>576
git push -u origin newbranch
578:デフォルトの名無しさん
11/11/09 20:32:13.01
>>576
2重管理地獄で悶えて死ねｗｗｗｗ