>>951 git checkout でリポジトリはとってこれますけど、git branch しても master しかありません。
リモートの hogehoge ブランチをローカルにもってくる方法がわからなくて質問しています。
こういうキチガイに親切にレスをする人をぼくは尊敬します
まあちょっと図々しいかもな。
レスつけてるようで全然答えてないのになぜか偉そうなやつって確かにイラつくよな。
質問すらろくに読んでない場合も多いし。
>>945 % git clone /path/to/repos
% cd repos
% git branch -r
origin/hogehoge
origin/master
% git checkout -b hogehoge origin/hogehoge
質問スレじゃないし答える義務なんてねえんだけどな
質問スレだって義務なんてないよ
>>955 お前こそ良くレスを読め。
”確かに”って書いてるくせに言ってることが流れと真逆だぞ。
>>952 >>956の通りのやり方で出来るよ。
git branch -r でリモートのブランチが表示されるから、それをcheckout -b で
ローカルブランチにフォーク。
git checkout origin/hogehoge で直接チェックアウトも出来るが、これだと名無しブランチになる。
てかチュートリアル読めば分かるって。
設定ファイル見てオーバレイステータスと実行するコマンドを決める
マルチTortoiseを希望
アップデート後に再起動しなくていいTortoiseを希望
bzrはtortoise入れても再起動しなくて良かったような
クオリティが低すぎて、再起動を求めることすら忘れてるだけだろ。
Bazaar 1.9 rc1の時に意図的に再起動を無くしたという話らしい。
Bzr1.9 と Hg の速度比較した人いない?
まだHgの方がはやいの?
バージョン管理システムのベンチマークプログラムがあると良いと思った。
自転車置き場をどうするかで揉めて企画倒れしそうだが。
エクスプローラのアドインだから、エクスプローラだけ再起動してやればいいんだけどね。
ログオフでも可。
ちゅうか、そろそろシェルエクステンションの意味無くなってきてない?
上の話見たけど、全部 git clone で運用すればいいんでないの?
なんでわざわざ branch なんて概念があるの?
便利だから。
>>956 ありがとうございます。でも>950で書いたように、
>git checkout -b hogehoge origin/hogehoge
でもエラーになってうまくいきません。
もしかしたら何か別のことが原因でうまくいかないのかもしれません。
だったらSVN使ってれば良いだろ
いちいち泣きつきに来るなよ
親切に答えようとしてる振りしてる自演乙
質問者も回答者もうざい。gitスレでやれ
うおー、checkout -b hogehoge origin/hogehoge がうまくいきました!
やったこと:
(1) git を 1.6 にアップデートして
(2) リポジトリを checkout し直して
(3) checkout -b hogehoge origin/hogehoge
うまくいかなかった原因は、git が古かったせいかもしれないし、
いろいろ試したせいでリポジトリがおかしくなってたのかもしれません。
とにかく最新版の git でチェックアウトし直したら、>956の通りにいけました。
偽蕪木ら某◇Googl8RmwA さま、辛抱強くアドバイスくださりありがとうございました。
でもgitわかりにくいよ。。。
だからgitなんかやめて、bzr使えばいいんだよ。
bzr使いやすくて最高だよ。俺は使った事無いけど。
gitのwindows版インストールしてみたんだけど、GUIは意味不明のエラーで起動しないわ、
git cloneも同じく意味不明のエラーで止まるわでダメダメだったぞ
gitやめて、bzr入れてみた。
bzr評判が良いだけあって最高だな。まだ起動してないけど。
985 :
982:2008/12/03(水) 20:11:22
ちなみに俺がインストールしようとしたのは、msysgitってやつ。
msysでもcygwinでもない、Windowsネイティブバイナリ無いの?
誰も使ってないけど至高のバージョン管理ツールbzr for Human Beings
hgが1.1になってたんで簡単なsvn/hg/bzr比較ベンチマークしてみた。
gitは使うきないので対象外。
環境:
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
Memory 2GB
データ:
svn export svn://gcc.gnu.org/svn/gcc/tags/gcc_3_4_2_release gcc_3_4_2
svn export svn://gcc.gnu.org/svn/gcc/tags/gcc_3_4_3_release gcc_3_4_3
結果: SVN(ver 1.5.1), HG(ver 1.1), BZR(ver 1.9)
SVN HG BZR(fmt1.6) BZR(fmt1.9)
3_4_2のコミット 1m17s 33s 40s 39s
3_4_2のpush ー 34s 55s 53s
3_4_3のマージ 6m30s 2s 17s 7s
マージ後push ー 2s 15s 14s
レポジトリサイズ 119MB 116MB 295MB 263MB
この結果だとまだまだhgの方がよさそうだ。
bzrのレポジトリサイズはちょっと耐えがたいか。
速度は秒単位であればbzrでも我慢できるが。
OSは?
ubuntu 8.10です。
>>970 分散型だったらclone+commitでブランチができちゃうのは宿命。
それに名前をつけたいことやあるだけ。
subversionのレポジトリの中ではファイル圧縮されてるらしいからなあ
>987
リビジョンが増えるにつれて、全コピーするhgのレポジトリサイズはどんどん増えていくでしょ。
svnはHEAD以外はリモートに置くから、影響が小さい。
bzrは--stackedオプションがあるから、まだ軽減される。
開発チーム内にデザイナが居て、画像ファイルとか差し替えると、これは顕著になる。
ああ、またbzr万能論を補強してしまった。
>>992 それで、
>>987のケースでbzrのレポジトリサイズが
有利になるクロスポイントはどのくらいレビジョンが
上がったときになるのかな?
机上の空論を唱えられるより実用的な数字が知りたいわけ。
そして--stackedをつけるとどのくらいの量が減るのかな。
そこんところkwsk
994 :
987:2008/12/04(木) 07:26:14
svnは当然ながら、hgもbzrも空の中央レポジトリを作り、
clone/branch作ってファイルをコミットしてから中央レポジトリ
へpushし、中央レポジトリのサイズを計ってる。
従って、svn/hg/bzrでのレポジトリ計測の条件は同じのはず。
>>992の
>svnはHEAD以外はリモートに置くから、影響が小さい。
は関係なく、svn/hg/bzrどれがどれより有利な条件という
ことはない。
>>992 リビジョンが増えるにつれて、全コピーするhgのレポジトリサイズはどんどん増えていくでしょ。
差分をとるはずだよ (hgbook 4.2.1)
次スレよろしく
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。