09/02/26 01:34:55
ああ、branchで作ったディレクトリを見失う（どこにブランチ作ったか忘れる）心配がないって事ね
でもそれmergeが優れているわけではなくて、単なるbranch方式の違いだよな
586:デフォルトの名無しさん
09/02/26 02:08:42
マージの優劣って言葉通りじゃなくて、マージトラッキングや
その自由度・速度を含めたことだと思うが･･･
587:デフォルトの名無しさん
09/02/26 02:16:08
Mercurialって、マージの自由度低くない？
統合する方向のマージに強制されてるような気になってる来るというか、
cherry-pickingしにくい仕組み。
むしろ、Subversionぐらいの放任主義の方が自由感がある。
588:デフォルトの名無しさん
09/02/26 02:28:45
git or mercurialは3-way マージでsubversionは2-way マージだったはず。
589:デフォルトの名無しさん
09/02/26 02:32:41
>>587
機能を追加するたびに、bookmarkがbranchを使えばそもそもcherry-pickingする必要がない。
gitとmercurialは両方とも、mergeとcherry-pickingを区別してたと思う。
590:デフォルトの名無しさん
09/02/26 02:50:41
>588
3-way マージって、
(1)自分が編集したバージョン
(2)第三者が編集したバージョン
(3)上の(1)の元になったバージョン
の3-wayでしょ？
なら、Subversionと一緒じゃん？
591:デフォルトの名無しさん
09/02/27 00:19:15
>>590
Subversionって、ファイル単位でコンフリクトしたらCになって終了（解消してね）
じゃなかったっけ。今は違うのかな。
svkとかGitだと行単位でぶつかってなければ良い感じにマージしてくれる。
592:デフォルトの名無しさん
09/02/27 00:22:56
CVSの昔から、行単位でぶつかってなければ自動マージだろう……。
593:デフォルトの名無しさん
09/02/27 00:25:56
行単位だよ。
594:デフォルトの名無しさん
09/02/27 00:53:35
>>590
gitとmercurialは(3)が(1)と(2)の両方の元になったファイル
595:デフォルトの名無しさん
09/02/27 09:56:06
Linuxレベルならともかく、普通の規模のプロジェクトとか
普通の業務利用とかでそんなに賢いマージが必要
なのは、ちょっとどうかという気もするが・・・
マージだけならSubversionで困らない。
会社でSubversion個人でGitだけど
596:デフォルトの名無しさん
09/02/27 11:02:52
も少し賢くてもいいけどなぁ
あと Subversion は遅くね?
597:デフォルトの名無しさん
09/02/27 12:16:30
TortoiseHGでコミットするとき、Mステータスのファイルにデフォルトでチェック付けたい。
どっかで設定できる？
コミットツールはinternalって設定にしてる。
598:デフォルトの名無しさん
09/02/27 15:48:06
分散SCMだと分岐したまま進められちゃうから、
共通先祖を考慮したマージが必要なんじゃないかな。
Mercurial の内部マージと diff3 のマージってどっちがいいのかな？
衝突時に共通先祖が表示されるんで diff3 使ってるけど・・・
599:デフォルトの名無しさん
09/02/28 03:32:14
デフォルトでチェックされてるけど
600:デフォルトの名無しさん
09/02/28 08:09:04
600
601:デフォルトの名無しさん
09/03/01 13:26:37
分散型のバージョン管理システムの場合、
それぞれのリポジトリはリポジトリ丸ごと
持っているという感じなんでしょうか？
あるリポジトリをマスターと決めたとして、
そのフルのクローンをそれぞれ持っているということでしょうか？
いまはSubversionを使っていて trunk, branches, tags 型で
かんりしてまして、branches の下の自分が作業を進める
ブランチだけ手元のワーキングコピーにチェックアウトして
作業しており、マージはマージ担当（まれに自分）に任せてます。
そもそも分散型だと trunk, branches, tags 型の
管理というのはやらないものなのでしょうか？
分散型のバージョン管理システムの紹介記事を読んでいると、
そもそも「ブランチ」というのはリビジョンツリー（というかDAG）
上の異なるヘッドことを指しており、リポジトリ上で別の
ディレクトリとして分岐されたものという意味ではないですよね？
確かに「ブランチするときはそのブランチ用のリポジトリを
作れば良い」という記述も見ました。そのときリポジトリ丸ごと
クローンするのでしょうか？巨大なプロジェクトだと一部だけ
クローンして作業を進めたいというのはあり得ると思います。
分散型だと「あるリポジトリが消失しても別のリポジトリを
マスターと思えばよい」という記述も見ましたので、
分散している各リポジトリはそれぞれ対等にフルのツリーを
持っているのでしょうか？
602:デフォルトの名無しさん
09/03/01 13:50:00
VCS毎に違いはあるだろうけど、たいていはローカル（というかハードリンク可能な場所）なら
ハードリンクでリポジトリの内容を共有して領域節約できる。
ネットワーク経由の場合もフルに取ってくるんじゃなくて、最新からこのリビジョンまでって指定も出来る。
「ブランチ」って言葉の使い方も、VCS毎に変わるから一概に言えないな。
gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。
結局のところいくら記事読んでも、実際使ってみないと実感わかないと思うよ。
きっと分散じゃないVCS使い始めたときもそうだっただろ。
Subversion使ってるなら、svkとかgit-svn使ってみるとか。
603:デフォルトの名無しさん
09/03/01 14:11:54
そもそも「リポジトリ」という言葉の意味すらシステムによって違うしな
>>601
端的に言うと、分散型の進め方では
「フルのクローンをそれぞれ持っている」という理解はおおよそ合ってる
各作業メンバーが、「masterの履歴＋自分が行った変更の履歴」を持ってるような感じ
> 巨大なプロジェクトだと一部だけ
> クローンして作業を進めたいというのはあり得ると思います。
一部だけ持ってこれるような仕組みがあるよ
たとえばBazaarなら、履歴なしで最新版のファイルだけを取ってこれるようなオプションがある
604:601
09/03/01 14:58:56
>>602-603 ありがとうございます
>gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。
分散型といってもいろいろあるんですね、流儀が（当たり前か）。
>>602 wrote ネットワーク経由の場合もフルに取ってくるんじゃなくて、
>最新からこのリビジョンまでって指定も出来る。
>>603 wrote たとえばBazaarなら、履歴なしで最新版のファイルだけ
>を取ってこれるようなオプションがある
リビジョン範囲は指定できるものもあるんですね。
「分散型」を十把一絡げで理解しようとしたのが間違いでした。
605:601
09/03/01 15:01:29
最も強く疑問に思ったのは、あるプロジェクトのリポジトリ内に
「アプリの主要部分、いくつかの下請けライブラリ、
ドキュメント、UI関係」などがあったとき、
自分が担当しているライブラリ、ドキュメントの部分だけを
クローンして作業を進めるということができるのだろうか、という点でした。
これは最初から「ドキュメント用のリポジトリ」などに分離
しておくのが分散型の流儀なのだろうか？という点です。
これもDVCSによって異なるのかもしれませんが。
もう一つの疑問が、そのように完全に分離したとして、
共通の祖先をもたない複数のリポジトリを複数あつめて
一つのプロジェクトを遂行するのは難しいのでは？ということです。
たとえばプロジェクトの途中で「これは共通のライブラリで実現するように分離しよう」
などという決定が 可能なのだろうか、と懸念しています。
Pythonを常用しているので、まずはMercurialとBazaarから主に上記の点について
実感をもつべく使い始めてみようと思いますが、DVCSの機能もさることながら
運用上のポリシー という側面も大きいと思うので、実際に使っておられる方の
アドバイス（ベターなプラクティス）があればぜひお聞かせください。
606:デフォルトの名無しさん
09/03/01 16:48:13
そもそも分離したいという目的は？
リポジトリの物理的大きさの問題であれば
いまさらそんな気にすることはないと思うけど・・・
管理面の規模の問題なら、分割するのもありかもね。
JDK7 なんかは分かれてるし。
分割した方が管理コストがさげられるならそうするべきでしょう。
607:デフォルトの名無しさん
09/03/01 18:47:10
URLﾘﾝｸ(sarabande.info)
ここの画像無くなってる？
608:デフォルトの名無しさん
09/03/02 20:27:43
>>601さん、なかなか興味深い質問ですね。
分散VCSを使い始めた人の意見や疑問点をもっと聞いてみたいので、ほかにも質問があれば遠慮なく書いてください。
もちろんすべてに答えられるわけではないですが、他の人にも参考になると思います。
>>606
ディスクスペースを節約するために必要なディレクトリだけ持ってくるというのはあり得る。
たとえばゲームのように画像や動画や音声ファイルがある場合、それらもリポジトリに登録するべきだけど、
そうするとリポジトリサイズが膨らみすぎて、いくらHDDが安いと言ってもちょっと困る。
リポジトリからとってくるネットワーク資源もばかにならない。
あと、ディレクトリごとにアクセス権をつけたいという要求もある。
たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
＃この場合はリポジトリを分けた方が自然かも。
609:デフォルトの名無しさん
09/03/03 02:43:14
>>608
メディアファイルをリポジトリに「登録するべき」と決めつけずに、
分散かどうかに関わらず、リソースなども照らし合わせて管理方法を検討すべきだろうね。
最新ファイルしかいらないのにそもそもリポジトリを公開すべきなのか、とかも。
サブプロジェクトへの権限委譲については、
やっぱりJDK7みたいにするのがいいんじゃないかな。
アクセス制限も分散は難しいし、ロックもないし、
人間どうしの折衝や信頼は結構重要。
610:デフォルトの名無しさん
09/03/03 09:52:12
>>605
あまり回答にはなってないだろうけど参考までに。
何度も書いたが、CVS は modules ファイルを駆使してリポジトリツリーの
好きなところからちぎってきて組み合わせられるのが便利だった。
管理が良くも悪くもファイル単位ゆえ、自作ライブラリディレクトリから
アプリに必要なファイルのみチョイスするような芸当もできた。
今は Subversion を飛ばして Mercurial を使用(試用)中だけど、さすがに
CVS のような細かいことはできそうにないし、ハードウェアリソースも KB 単位で
ケチるような状況ではないので、ライブラリに関しては独立したリポジトリとして
開発時のディレクトリ構成を工夫している。
ただ、ファームウェアのような非常に小さなプロジェクトがたくさんあるような状況では、
いちいちリポジトリを分けるか一まとめにしてしまうかは悩むところ。分けると同期も面倒に
なってくる。今のところ、とりあえず一まとめにしているけど、もっといい方法はないか思案中。
大きなプロジェクトで使うことに主眼が置かれているんだろうな。
611:デフォルトの名無しさん
09/03/03 22:23:29
>>608
> あと、ディレクトリごとにアクセス権をつけたいという要求もある。
> たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
> ＃この場合はリポジトリを分けた方が自然かも。
こういう事やりたいなら、PerforceやTeam Foundation Serverのような、
クライアント・サーバー型のバージョン管理システムが適してる。
612:デフォルトの名無しさん
09/03/03 23:08:29
python3000で組まれたバージョン管理ツールってないのかな？
bzrやhg何かの古株が対応するよりも新しく作る方が
早いかもしれんし。
613:デフォルトの名無しさん
09/03/04 13:17:49
windowsで日本語も使えるのはどれになるのでしょうか？
darcsの話題があんまり出ないのは死んだプロジェクトになってしまったのでしょうか？
614:デフォルトの名無しさん
09/03/04 14:19:36
>>613
全部試せよ。
それが嫌ならSubversionを押し戴け。
615:デフォルトの名無しさん
09/03/04 21:21:08
日本語を使えるので人に勧められるのはSubversionしかない
616:デフォルトの名無しさん
09/03/04 23:22:18
日本語コミットメッセージが書ければうちでは十分。
617:デフォルトの名無しさん
09/03/04 23:22:27
svnで不満があるならsvk使えばいいし。
svn最強。
618:デフォルトの名無しさん
09/03/05 02:30:42
svnは良くも悪くも無難でいいけど、svkはいろいろ酷い目にあった。
619:デフォルトの名無しさん
09/03/05 09:52:59
TortoiseHgの欠点は、
・付属のhgだと日本語ファイル名×
・TortoiseHgだと日本語ファイル名OK
・でも、hg mv がないｗｗｗ
ので、現時点で日本語ファイル名のファイルの移動する手段がありませんｗ
ワロタ
620:デフォルトの名無しさん
09/03/05 09:53:30
> ・でも、hg mv がないｗｗｗ
・でも、TortoiseHgにはhg mv 相当がないｗｗｗ
スマソ
621:デフォルトの名無しさん
09/03/05 09:55:53
>>613
WindowsでGUIでやりたいとなると、TortoiseSVNしか選択子なしですわ
622:デフォルトの名無しさん
09/03/05 10:51:26
肢
623:デフォルトの名無しさん
09/03/05 11:00:22
trac + svnで充分満足であります
624:デフォルトの名無しさん
09/03/05 15:21:59
hg来たな
625:デフォルトの名無しさん
09/03/05 18:09:59
>>624
0.7入れてみた。
毎回アンインストール→再起動→インストール→再起動を強いられるのは勘弁して欲しいな。
あと、テーマ機能とか付いたみたいだけど、そんなことしてる場合じゃないだろって感じ。
まだまだですな。
626:デフォルトの名無しさん
09/03/05 19:38:47
>>610
ライブラリ毎にリポジトリをつくったら、あとは
プロジェクトのリポジトリをつくって
ライブラリをhg pull --forceで取り込んでmergeすればok.
627:デフォルトの名無しさん
09/03/05 20:00:26
git push でエラーが出ます。
$ git push
Counting objects: 9, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 924 bytes, done.
Total 6 (delta 3), reused 0 (delta 0)
To git@github.com:myname/project.git
3648514..9fc4c3a ot -> ot
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'git@github.com:myname/project.git'
これはどういう意味で、どう対処すればいいでしょうか。
628:デフォルトの名無しさん
09/03/05 20:04:29
うちの環境では0.7+ini設定で日本語使えてる感じがするな
まあたまたまなのかもしれん
629:デフォルトの名無しさん
09/03/05 20:07:30
>>626
意味がよくわからない。
最後の節の、小さなプロジェクトがたくさんある場合の対処法？
630:デフォルトの名無しさん
09/03/05 22:53:08
>> 628
TortoiseHg 0.7にwin32mbcsエクステンションの設定で、わりといい線までいくみたいですね。
でも、ディレクトリ名の最後の文字が0x5cを含んでいたりすると、まだコケる模様。
631:デフォルトの名無しさん
09/03/05 22:53:56
アンカー失敗したorz
632:デフォルトの名無しさん
09/03/06 00:39:14
>>627
>>282
633:デフォルトの名無しさん
09/03/06 02:06:53
>>630
多分TortoiseHgだとファイル名を指定してaddしてるんで動いているように見えるだけ。
Mercurial 1.2でも直ってない。
634:デフォルトの名無しさん
09/03/06 02:15:23
正直、日本語ファイル名の対応でいうと
SVN＞bazzar＞git＞mercurial
何もしないでバイト列で扱うgitのほうが、まだマシだ
635:デフォルトの名無しさん
09/03/06 04:50:33
もう疲れたよ、パトラッシュ・・・
636:デフォルトの名無しさん
09/03/06 08:58:53
Mercurial Patch
URLﾘﾝｸ(bitbucket.org)
637:デフォルトの名無しさん
09/03/06 10:52:03
git のfast forwardって何ですか。
マニュアルみてもさっぱりわかりません。
638:デフォルトの名無しさん
09/03/06 11:10:00
>>636
何勝手に2chの著作物を断りもなく公開してんだよ？
639:デフォルトの名無しさん
09/03/06 22:07:18
>>635
マネスレに（・∀・）ｶｴﾚ!!
640:デフォルトの名無しさん
09/03/07 01:36:05
1.6.2
641:デフォルトの名無しさん
09/03/07 01:42:16
>>637
URLﾘﾝｸ(www.kernel.org)
642:デフォルトの名無しさん
09/03/07 09:27:55
/
,. ､ / ／
,.〃´ヾ.、 / ／
／ |l ', / ／ 2chの著作物です！
,､ ,r'´ ||--‐r､ ', パッチは2chの著作物でした！
l.l. ,..ィ'´ l', '.j '. パッチは2chの著作物でした！
'r '´ ',.r '´ !| ＼
l! ....:.:.:.:.:.:ヽ､ ,ｌ ＼
ゝ､.,_ ---‐‐‐----ゝ､ノ
| |
.| |
| |
| |
| |
643:デフォルトの名無しさん
09/03/07 19:40:51
個人で使う分には関係ないだろ。
本家には未来永劫取り込まれないだろうが。
644:デフォルトの名無しさん
09/03/07 19:52:07
だがちょっと待ってほしい。
２ちゃんねるが初出だとどうして言えるだろうか。
どこかに公開されていたものが２ちゃんねるに投稿されたのではないか。
２ちゃんねるにそれを書き込んだ人物が、
当該文書の原著作者であったとどうして証明できるだろうか。
645:デフォルトの名無しさん
09/03/07 20:00:20
方式主義なら話は単純だったんだろうか。
646:デフォルトの名無しさん
09/03/07 20:32:44
話を3日前にもどそう
647:デフォルトの名無しさん
09/03/07 22:28:02
bzr revert -r date:2009-03-04
648:デフォルトの名無しさん
09/03/08 02:27:26
著作権ってある程度芸術性みたいなのが求められたりするし、
そのパッチ単体程度だと、著作物にならないんじゃね。
まぁ、慣例的にもそこに文句つけたりしないだろうし、
どうでもいいが。
649:デフォルトの名無しさん
09/03/08 04:31:46
日本ではたぶんそうなる。
問題は、日本だけで開発されてるようなプロジェクトじゃないってこと。
将来の開発者を含む全ての開発者が、今後活動する可能性がある全ての国や地域の法規に照らして判断する必要がある。
そうじゃないと、例えば何も知らずに加わった新開発者が、旅行先で突然逮捕されるかもしれない。
ぶっちゃけ、そんなリスクのあるパッチ取り込むより、自分達で書き直すほうがまし、っていうか。
650:デフォルトの名無しさん
09/03/08 09:00:28
TortoiseHg付属hgの日本語ファイル名周りしらべたけど、hg mvが駄目ってのは勘違いだったみたいスマソ。
hg commit(hg ci)で、addした駄目文字ファイル名のファイルがコミットできないみたい。
hg mv が駄目だと思ったのは、mv時にremoveしてaddされるので、その後のcommitがおかしいためみたいです。
検証過程：
>touch 表の噂.txt # touchは空ファイル作ってるだけです。
>touch test.txt # ただしBorland版touchね
>hg st
? test.txt
? 表の噂.txt
>hg ci -A -m "added from command line" # 追加しながらコミット。ここまではよい
adding test.txt
adding 表の噂.txt
>hg st # コミットできてねえ！add相当は一応できてる
A 表の噂.txt
>hg add . # 念のため
>hg ci -m "added from command line retry"
nothing changed # ええ！？無視ですか？
>hg st
A 表の噂.txt # ダメポｗｗｗ
つーわけで、>>636 を試してみるぜ
651:デフォルトの名無しさん
09/03/08 09:13:43
あれ？もしかして、>>636ってソースからコンパイルがいるのかよ・・・
Bazzarみたいにプラグイン形式じゃないのか orz
面倒クセー
652:デフォルトの名無しさん
09/03/08 13:04:22
TortoiseHg 0.7 かなりよいですねー。
コミットツールがようやく置き換えられて、ファイル名や以前のコミットログの参照は、
駄目文字含め文字化けしなくなった。
diffの表示も中身がSJIS、UTF-8でも問題ない。
(このコミット時の簡易diff表示は他のTortoise系でもほしいくらい)
残念ながら、Rename Fileはリネームのダイアログが文字化けするし、
win32mbcsのエラーで実際にリネームできないし、
ドラッグアンドドロップでのリネームはまだ非対応なものの、
Guess Renamesで適当にリネームした後、リネームの自動検出ができる。
そっちは駄目文字含め、日本語ファイル名OK、なので実質は問題ないだろう。
これで、コマンドライン版 hg なくても日常作業は事足りるようになった。
しかし、hgのコマンドライン版は日本語リソース追加されてて、日本語で出てきてびっくりしたｗ
653:630
09/03/08 13:46:07
>>652
日本語ファイル名対応は、まだ完全ではないようなので要注意ですよ。
654:デフォルトの名無しさん
09/03/08 14:23:16
>>651
本体の1.2のソースダウンロードしてローカルリポジトリ作って>>636のパッチ当てて
できたhgext/win32mbcs.pyとmecurial/util.pyをTortoiseHg/library.zipの中の同じ位置に配置すればとりあえず動くっぽい
655:652
09/03/08 15:11:02
TortoiseHg 0.7 で 実質、>>619の問題は一応解消した。
>>650 は相変わらず駄目だが、直接ファイル名指定してやると一応通る
>hg ci -m "added from command line retry" 表の噂.txt
>hg st # OK
>
だけどまあちょっと怖いね。
しかし、bitbucket.rogに日本語ファイル名のファイルをpushしたら、
未だに更新ファイルの詳細ページがInternal Server Errorで見れねえｗ
これ、大分前から変わってないな
656:デフォルトの名無しさん
09/03/08 21:34:15
TortoiseHg 0.7のコミットツールの
ログ入力欄のフォントが気に入らない。
変更できねえかな。
657:デフォルトの名無しさん
09/03/10 19:06:14
TortoiseHgの翻訳をLaunchpadでするって激しく何か間違っている感が…。
658:デフォルトの名無しさん
09/03/11 20:31:36
git push
と
git push origin master
の違いがわかりません。だれか教えて。
あと
git checkout -b dev origin/dev
としたあとにpushするのって、
git push
でいいのか
git push origin dev
としなきゃいけないのか、どっちでしょう。
マニュアルのここを読めでもいいので、教えてください。
659:デフォルトの名無しさん
09/03/11 23:50:36
>>658
git push だけの場合は<repository>と<refspec>を省略したことになるので、
.git/configにremoteとmergeが指定されていればそこにpushしようとするよ。
git checkout -b dev origin/dev とした場合は、devにremoteとmergeが指定されてる
はずなので、省略してgit pushだけでもおk。
git pushはExamplesが俺はすごい分かりやすいと思う
URLﾘﾝｸ(www.kernel.org)
660:デフォルトの名無しさん
09/03/12 11:02:25
>>659
うおーなんとわかりやすい説明。
.git/config みたら
[branch "dev"]
remote = origin
merge = refs/heads/dev
と書いてありました。なるほど。
どうもありがとうございました。
661:デフォルトの名無しさん
09/03/12 17:54:40
Bazaar and Mercurial SCM services launched
URLﾘﾝｸ(apps.sourceforge.net)
>The SCM platforms supported by SourceForge.net differ in capabilities. All of our SCM services include rsync backups, web-based browsing, authentication with SourceForge.net accounts, and direct support by SourceForge.net staff.
662:デフォルトの名無しさん
09/03/12 19:42:09
git pull --rebase
と
git fetch
git rebase origin
には違いはありますか。
663:デフォルトの名無しさん
09/03/12 23:11:56
>>661
Gitには既に対応してる？
664:デフォルトの名無しさん
09/03/12 23:31:40
>>661
なんということだ
Bazaarユーザーの俺はlaunchpadとSourceForge.net、どっちを使えば
665:デフォルトの名無しさん
09/03/13 11:29:09
URLﾘﾝｸ(git.sourceforge.net)
こいつがGit対応を阻んでいるのかｗ
666:デフォルトの名無しさん
09/03/13 21:19:25
sourceforgeはgitにずいぶん前に対応しなかったっけ?
URLﾘﾝｸ(slashdot.jp)
667:デフォルトの名無しさん
09/03/13 22:20:48
>>666
jpだけって書いてあるじゃんwww
668:デフォルトの名無しさん
09/03/14 01:46:59
Git だけ >>661 より少し前に対応済み。
"Git now available for SF.net hosted projects 2009-02-18"
URLﾘﾝｸ(sourceforge.net)
669:デフォルトの名無しさん
09/03/14 08:34:01
>>665
warota
670:デフォルトの名無しさん
09/03/14 09:13:46
結局git, hg, bzr, cvs, svnが使えるのか＞sf.net
671:デフォルトの名無しさん
09/03/16 18:26:48
git branch -r したときに、たとえば
origin/HEAD
origin/master
origin/experiment
origin/development
と出てたとします。
ここで、リモートのリポジトリから origin/development が削除されたとします。
しかし手元で git fetch してから再度 git branch -r すると、origin/development が残ったままになっています。
つまり、この状態では git branch -r が正しい情報を表示してくれない（または git fetch しても
rogin/development が削除されたという情報が反映されない）ということです。
このあと git branch -r -d origin/development を実行すると表示されないようにはなりますが、やっぱり気持ち悪いです。
長くなりましたが、質問をまとめると、リモートブランチの*正確な*一覧をとってくるのはどうしたらいいでしょうか。
または git branch -r したときに、すでにリモートブランチで削除ずみのものを表示させないようにするにはどうしたらいいでしょうか。
よろしくお願いします。
672:デフォルトの名無しさん
09/03/17 23:37:37
>>671
git remote prune はどうかな。
673:デフォルトの名無しさん
09/03/18 15:06:17
>>672
まさにそれでした。
$ git remote prune --dry-run origin
Pruning origin
URL: git@github.com:user1/project1.git
* [would prune] origin/development
$ git remote prune origin
Pruning origin
URL: git@github.com:user1/project1.git
* [pruned] origin/development
どうもありがとうございました。
674:デフォルトの名無しさん
09/03/21 22:06:38
TortoiseHg 0.7.1 (with Mercurial 1.2.1)、インストール前に
旧版をアンインストールしておく必要がなくなったようです。
675:デフォルトの名無しさん
09/03/22 00:50:08
TortoiseHg 0.7.1を試してみてRename Fileの化け文字は
ある程度改善したみたいだ。しかしファイル名に「ソ」が
あるとやはり化ける。あと少しで完璧なのに惜しい。
676:デフォルトの名無しさん
09/03/22 01:14:54
>>675
予とか表は大丈夫なのか？
677:デフォルトの名無しさん
09/03/22 02:21:57
>>675
>>636
678:デフォルトの名無しさん
09/03/23 13:28:13
TortoiseHGのGUIツールキットがなかなかよさげなんですが、あれって何使っているんでしょうか？
679:デフォルトの名無しさん
09/03/23 18:38:33
>>678
gtk
680:デフォルトの名無しさん
09/03/24 00:16:26
TortoiseGitでgithub使えている人いる？
mkdir magemoge
cd magemoge
git init
touch README
ToritoiseGitで追加、コミット
git remote add origin git@github.com:user_name/magemoge.git
ToritoiseGitでpush
以下のエラー
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
どうすりゃいのかな？
681:680
09/03/24 00:27:07
ssh周りかな？と重い
TortoiseGitのオプションで、sshにplink.exeを指定し、
Pageantを立ち上げて鍵を追加し、実行したのですが、やはりエラーがでてしまいます。
github側にはすでに、対応する公開鍵をついかしてあります。
> git.exe push "origin" master
> fatal: The remote end hung up unexpectedly
うーん。
682:680
09/03/24 01:13:56
何度もスマン
コマンドラインgitだと大丈夫でした。
`ssh-agent -k`を実行して、git push master original で無事いけました。
TortoiseGitの時はどうすんだろ
683:デフォルトの名無しさん
09/03/24 03:30:39
問題山積みですな
684:デフォルトの名無しさん
09/03/24 10:22:41
TortoiseHg 0.7.2
685:デフォルトの名無しさん
09/03/24 11:14:10
まだ>>636が必要そうだね
686:デフォルトの名無しさん
09/03/24 18:35:35
git push すると次のようなエラーがでます。
このエラーは何を意味していますか。
またどう対処すればいいでしょうか。
$ git push
Counting objects: 159, done.
Delta compression using 2 threads.
Compressing objects: 100% (47/47), done.
Writing objects: 100% (81/81), 10.66 KiB, done.
Total 81 (delta 58), reused 47 (delta 33)
To git@github.com:myname/myproject.git
c62e2a8..cd4f2f0 dev -> dev
! [rejected] master -> master (non-fast forward)
! [rejected] experiment -> experiment (non-fast forward)
error: failed to push some refs to 'git@github.com:myname/myproject.git'
よろしくお願いします。
687:デフォルトの名無しさん
09/03/25 10:33:22
TortoiseGitの右ドラッグ＆ドロップで "Git Copy and rename versioned item here"という選択肢が出るのですが、
現バージョンでは実装されていないものの、コマンドライン版gitでは何に値するものなのでしょうか？
他にも、
・Git Move versioned items(s) here → git mv 相当？
・Git Move and rename versioned items here → 同上
・Git Copy versioned item(s) here →これもなんだろ？
などがコンテキストメニューで出ますね。
688:687
09/03/25 10:49:54
assert(?) - git equivalent to “svn copy” for forking files with history?
URLﾘﾝｸ(markpasc.livejournal.com)
ああ、普通にコピーするだけでも一応以下のコマンドで感知はできるのか･･･
git log -C -C --name-status --no-walk
なるほど。TortoiseGitの方はコピーしたかどうか、というのはわからないみたいｄせいあｔ。
689:デフォルトの名無しさん
09/03/27 13:38:42
ためしに、MercurialでXAMPP(1万ファイル300MBくらい)を突っ込んでみたんですが、
XAMPPのアップグレード後で更新ファイル数が多いと
TortoiseHgがハングしてしまうｗ
Intel Q6600程度のCPUだと返ってきません
コマンドライン版hgだとサクサクですね。
Tortoiseの方はあまり大きなプロジェクトは考えられてないもんですかね？
690:デフォルトの名無しさん
09/03/27 13:39:53
訂正
> TortoiseHgがハングしてしまうｗ
TortoiseHgでコミット時、ウインドウがハングしてしまうｗ
コマンドライン版だと、hg commitやhg add .ともに軽いです。
691:デフォルトの名無しさん
09/03/27 13:42:04
>>689
また訂正スマソ
> > TortoiseHgがハングしてしまうｗ
> TortoiseHgでコミット時、ウインドウがハングしてしまうｗ
コミット時に立ち上がるウインドウがハングしてしまう
です、なので、TortosieHgだとコミットができません orz
まあ、XAMPPは日本語ファイル名はないみたいなのでコマンドライン版でも問題ないのですが
692:デフォルトの名無しさん
09/03/28 00:01:54
TortosieSVN でも、よくあること。
しばらく経ってやりなおす。
693:デフォルトの名無しさん
09/03/28 17:36:10
俺はログオフしてるわ
次同じことやってだめなら諦めてコマンド打ってる
694:デフォルトの名無しさん
09/04/01 03:59:16
python subversion -> mercurial決定
URLﾘﾝｸ(mail.python.org)
695:デフォルトの名無しさん
09/04/01 04:04:35
>694
ハゲがバザーよりsvnユーザーにとって学習しやすいってのは、
どの辺の話だ？
696:デフォルトの名無しさん
09/04/01 04:35:49
>>695
bazaarのメーリングリストでも同じこと言ってるやつがいるなw
bazaarのメーリングリストでキレながらStephenが説明してるから見て来たら？
697:デフォルトの名無しさん
09/04/01 05:59:45
祭り会場（エイプリルフールネタじゃないよ。）
【ネット】 朝日新聞編集局員（４９）、２ちゃんねるで荒らし行為。差別を助長する書き込みも…朝日、「処分します」と謝罪で★３０
ｽﾚﾘﾝｸ(newsplus板)
698:デフォルトの名無しさん
09/04/01 10:20:00
>>697 通報した
699:デフォルトの名無しさん
09/04/01 18:34:07
>>695
Guidoが勝手に言ってるんだから本人に聞けば？
700:デフォルトの名無しさん
09/04/01 20:25:21
TortoiseHg 0.7.3
701:デフォルトの名無しさん
09/04/02 08:11:07
駄目文字ファイル名には対応したが、駄目文字フォルダ名には対応できてない気がする
702:デフォルトの名無しさん
09/04/02 17:16:18
>>701
Mercurial自体が対応してないのに？
703:デフォルトの名無しさん
09/04/02 23:16:39
バージョン管理システムのバージョンを管理するのが面倒くさい。
バージョン管理システムのバージョンを管理するシステムは無いの？
704:デフォルトの名無しさん
09/04/03 00:54:05
パッケージ管理システムでも使えよ
705:デフォルトの名無しさん
09/04/03 15:05:50
質問があるのですが、よろしいでしょうか？
バージョン管理システムで「この行のローカル変更を無視する」ような指定の
できるものはありませんか？
例えば、設定ファイルなど、個々のユーザや環境ごとに内容を書き換える必要
のあるファイルをバージョン管理しようとすると、個々のローカルの変更が当
然、競合してしまいます。
しかし、このファイルをバージョン管理から外すと、新しい設定項目が増えた
ときにも、全ユーザの設定ファイルをアップデートすることができません。
そこで、たとえば
String db_name = "db_(ユーザ名)"; // svn:ignore
という具合に、svn:ignore の出現する行はバージョン管理の対象から外す、と
いった機能がほしいのです。
レポジトリには svn:ignore を含まないコードを登録し、各ユーザがチェック
アウト後に自分に適した値に書き換えてから、自分で svn:ignore と書き加え
ます。その後はその行だけ、バージョン管理システムから無視されるようにな
るので、アップデートすればその行以外は更新されます。
また、svn:ignore の書かれていない行を変更してコミットすれば、レポジトリ
に登録されたコードは当然、変更されます。
こんな機能を持つバージョン管理システムはないでしょうか？
--
もしかして分散バージョン管理システムなら、こういう使い方もできるのでしょ
うか？
706:デフォルトの名無しさん
09/04/03 15:13:01
>>705
設定ファイル側で個々のユーザ毎の設定だけ別ファイル作るとかして対応したら？
707:705
09/04/03 15:26:19
>>706
それはある程度やっておりますが、そういう個人ごとのファイルを中途半端に
バージョン管理したいのです。設定項目が増えたりしますから。
今は、設定項目が増えたりするときは、メーリングリストで通知しています。
もっとうまい方法がないかと思うのです。
708:デフォルトの名無しさん
09/04/03 16:44:32
コミットのトリガーで動く前処理スクリプトか、
svnの代わりに呼ぶラッパー作れば？
709:705
09/04/03 17:27:21
>>708
それはいいかもしれませんね。
ただ、コミットのトリガーだと、ユーザ環境では「変更されたファイル」とし
て扱われてしまうし、
svnの代わりのラッパーは、ユーザのOSやクライアントソフトの種類が多くて難
しそうです。
710:デフォルトの名無しさん
09/04/03 18:18:09
>>705
分散型なら各自の設定ファイルもバージョン管理できるだろうけど、
それだけの為に分散型にするのはどうだろうね。
あなた一人だけでやってるなら頑張って使い方覚えればおkだけど。。。
antとかrakeみたいなので設定ファイルをジェネレートするようにしたほうが
適してるかも。
711:デフォルトの名無しさん
09/04/03 18:46:32
xmlでもiniでもconfigでも、拡張子の後に更にsampleとか拡張子付加して管理してる
使う側が勝手にマージしろって感じに
712:デフォルトの名無しさん
09/04/03 18:47:42
んでコミットされないようにignoreにも登録
713:705
09/04/03 19:13:18
>>710
おっしゃるとおり、当分はSubversionから離れることはできないでしょう。
分散型については将来に備えて知っておきたいと思っています。
ant や rake については、毎回ユーザが設定値を与えるならわずらわしいし、
値を保持するなら、その値をどうバージョン管理するかという話に。
>>711-712
それはTortoiseSVNのチュートリアルが推奨している方法ですね。
（サイトが落ちているようなのでキャッシュ）
URLﾘﾝｸ(72.14.235.132)
うちもそうしているのですが、テンプレートが更新されても気づかないんです。
ユーザにマージさせるのに、メーリングリストで通知することになります。
714:デフォルトの名無しさん
09/04/03 20:13:50
別にそれで良くね？
あとはpost-commitにでも特定のファイルがコミットされたら
注意しやすいように、分かりやすくなるようにスクリプト書くだけじゃん
715:705
09/04/03 21:08:44
>>714
なるほど、テンプレートファイルが更新されたら、自動でMLにメールを投げる
とかですね。
結局、その辺に落ち着くしかないのかもしれません。自分の当初のアイディア
も、例えば設定項目が増えた場合、その増えた値を個々のユーザに書き換えて
もらう必要があるなら、通知が必要なようですし。
716:デフォルトの名無しさん
09/04/04 01:09:39
>>705
うちはgit使ってるけど、
- ベースとなるブランチをmasterとする
- ホスト毎にそのホスト固有の修正を行うブランチを用意(host/foo, host/bar, ...)
- masterに更新があった場合はgit rebase master host/fooとして各ホスト用データを更新
としてる。
717:デフォルトの名無しさん
09/04/04 08:47:23
>>716
便乗質問させてください。
その場合は、ローカルの仕事を本家にcommitしたいときはcherypickするのでしょうか？
そのままmergeしちゃうとホスト固有の部分も区別なくmergeされちゃうので、
まずいですよね。
718:716
09/04/04 16:29:32
>>717
そもそもhost/fooではホストローカルな修正しかしないので、masterにそういう修正を持っていくことはないよ。
masterに持っていきたくなるような修正はmasterで作業すれば良いんだし。
それでも誤ってmasterで行うべき作業をhost/fooでしてしまうことはあるかも知れない。
そういうときは
- まだコミットしてないならgit checkout -m masterでブランチ切り替えて作業継続。
- 既にコミットしてたらmasterで該当コミットをgit cherry-pickしてから
ホストローカルなブランチではgit resetやgit rebase -i masterで該当コミットを抹消。
としてる。
719:636
09/04/07 02:47:46
ファイル構成が大幅に変わってpatchがあてれなくなっていたので更新した
720:デフォルトの名無しさん
09/04/07 04:04:43
gitでhttp:/server/proj.gitからコミットasdf1234....を取りたい
んだけど、どうやればいいの？
全部取ってrevertを使ってみたが訳が分からん。
あまりに説明が無さ過ぎて泣ける。
721:デフォルトの名無しさん
09/04/07 10:35:04
全部取ってるなら
git checkout asdf1234
でいいんじゃないか？
722:デフォルトの名無しさん
09/04/07 18:42:00
>>713
各自用のバージョン管理しないローカル設定ファイル(ignoreされる)を
用意して、テンプレート設定ファイルの各値を上書きするように
ビルドツールを組んで、実行環境が構築されるようにしてやってるよ。
この場合、テンプレートにローカル設定がマージされるので、
ローカル設定ファイルの内容は古くても動く可能性がある。
もし各環境用の設定も全てあなたがメンテしないといけないなら、
各環境用にブランチ作るとかかなー
723:デフォルトの名無しさん
09/04/08 02:47:45
tracがパッケージとして既にあるubuntuか
安定性のcentosか
どっちでリポジトリ関連の鯖たてようかなあ
724:デフォルトの名無しさん
09/04/08 08:56:58
ubuntuのパッケージって結構古いのばっかりじゃなかったっけか。
あと日本語化するならapt使って入れるのはやめといた方がいい希ガス。
725:デフォルトの名無しさん
09/04/08 21:34:44
Ubuntu,Debianはbackportsで多少新しいのが入る。
CentOSはrpmforgeで同様に。
日本語化するならtracをいったん入れる直前までやってtracに必要なパッケージをメモって、
で必要なパッケージを入れて、日本語版Trac入れる、かな。
あと、ちょいとスレ違いなので、Tracの話題ならこっちの方がよいかと。
【バグ管理】 BTS使ってる？【追跡ﾞ】 ２
ｽﾚﾘﾝｸ(tech板)l50
726:デフォルトの名無しさん
09/04/08 23:25:22
メッセージ翻訳担当募集
URLﾘﾝｸ(groups.google.com)
＞なぜかリリースノートには記載されていないのですが（笑）、
＞一応 Mercurial 1.2 版からヘルプ類が日本語化されています。
＞しかし、ちょっと試してみればお分かりのように、まだまだ翻訳網羅率が
＞高くありません。とはいえ、数が数なので、私1人の翻訳では、流石に
＞ペースアップにも限界があります。
727:デフォルトの名無しさん
09/04/09 02:51:34
>726
日本語のmanがかなり古いんだが、そろそろ更新しないのかな？
mercurial wiki上に有るんなら俺が訳してもいいんだが。場所違うし。