2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

バージョン管理システムについて語るスレ6

1 :デフォルトの名無しさん:2010/04/07(水) 20:40:36
●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
【分散型バージョン管理】 Mercurial 【hg】
http://pc12.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://pc12.2ch.net/test/read.cgi/tech/1265951333/

●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/

2 :デフォルトの名無しさん:2010/04/07(水) 20:46:44
●関連サイト
CVS
ttp://ximbiot.com/cvs/wiki/
Subversion
ttp://subversion.tigris.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx

●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓)
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
Git入門
ttp://www8.atwiki.jp/git_jp/
Bazaar Documentation Overview
ttp://wiki.bazaar.canonical.com/Documentation
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial

3 :デフォルトの名無しさん:2010/04/07(水) 22:37:23
ごめん、前スレで告知するの忘れてた。

4 :デフォルトの名無しさん:2010/04/07(水) 22:43:28
前スレからの続きだけど、タグやブランチの扱いに関しては Subversion はかなり異端だと思う。
「機能がないから運用で回避」みたいな。

5 :デフォルトの名無しさん:2010/04/07(水) 22:46:32
>>4
内部実装はあれでもいいんだけど、ユーザに見せるなやって思うわ



6 :デフォルトの名無しさん:2010/04/07(水) 23:14:40
スレ立て乙

7 :デフォルトの名無しさん:2010/04/08(木) 01:41:55
>>4
ディレクトリがあればタグやブランチはいらないと言うのがsubversionの考え方

8 :デフォルトの名無しさん:2010/04/08(木) 06:32:58
面白いな。
リーナスに罵倒されるぐらい CVS を踏襲しようとしてるのに、
妙なところで独自性を出してるという。

9 :デフォルトの名無しさん:2010/04/08(木) 07:03:03
ClearCaseの使い勝手ってどんな感じ?

10 :デフォルトの名無しさん:2010/04/08(木) 07:29:09
>>9
クソってのが定説だな

11 :デフォルトの名無しさん:2010/04/08(木) 07:51:29
>>5
ユーザが自由に運用しておくれ、という意味だと思ってた。
その割には、ベストプラクティス系のドキュメントを見たことがないが。

12 :デフォルトの名無しさん:2010/04/08(木) 09:03:14
>>7
バージョン管理システムがなければ
フォルダを作ってこそにコピーすることになると思うけど
それと全く同じイメージで使えることを目指したんだろうね

13 :デフォルトの名無しさん:2010/04/08(木) 10:09:44
>>8
それが svn コミュニティのあほなところ。
svn はすっ飛ばして正解だった。

14 :デフォルトの名無しさん:2010/04/08(木) 10:26:58
>>13
一度は触っとけよ
Tortoiseの使い勝手だけは間違いなく一級品だぞ
プログラマ以外にバージョン管理を使ってもらうには未だSVNが最高でデファクト

15 :デフォルトの名無しさん:2010/04/08(木) 11:02:01
最高でデファクトかどうかは兎も角、Tortoiseとかウェブクライアントはよくできているみたいね。
CVSからsvnに引き継いだプロジェクトは事実上死滅したし、
svnでスタートしたプロジェクトは全てbzrに引き継いだから私のところでは最早使ってないけど。

16 :デフォルトの名無しさん:2010/04/08(木) 11:13:16
>>15
??
RubyはCVS→SVNだけど?

17 :デフォルトの名無しさん:2010/04/08(木) 11:25:48
15は突然自分語りを始めただけじゃねぇの

18 :デフォルトの名無しさん:2010/04/08(木) 11:26:12
>>16
その2行目は、3行目の「私のところ」の話だろう。

19 :デフォルトの名無しさん:2010/04/10(土) 21:25:42
いつになったらまともに日本語ファイル名を扱えるgitクライアントが出てくるんだよ。
cygwinとかいうのは無しで。

20 :デフォルトの名無しさん:2010/04/10(土) 21:56:01
>>19
gitユーザのありがたい仰せによると、
1. Windowsダっせぇ
2. んなもんどうせバイナリファイルだろ?svn使っとけやゴルァ
等々とても前向きなので、来世紀までには改善されるでしょ。

21 :デフォルトの名無しさん:2010/04/10(土) 22:45:12
これだからgitユーザーはクッセェんだ

22 :デフォルトの名無しさん:2010/04/10(土) 23:09:35
>>19
UTF-8なら問題ないよ。
Windowsとかいうのは無しで。

23 :デフォルトの名無しさん:2010/04/10(土) 23:10:58
一つの言語に対するエンコーディングが複数存在することを理解させる
複数のエンコーディングを排して統一するものとしてUNICODEでは不十分なことを理解させる


24 :デフォルトの名無しさん:2010/04/10(土) 23:20:58
UNICODEが不十分だから他のエンコーディングを相互変換するのが気持ち悪いんじゃないの?

25 :デフォルトの名無しさん:2010/04/10(土) 23:42:38
ファイル名にカッコ株とか携帯絵文字でもはいってんのか?

26 :デフォルトの名無しさん:2010/04/10(土) 23:46:25
別に完璧なんか求めてなくて、svnでできる程度できれば問題ないんじゃないの?

27 :デフォルトの名無しさん:2010/04/11(日) 00:32:26
カッコ株はunicodeにあるだろ
携帯絵文字もそのうち入るし

28 :デフォルトの名無しさん:2010/04/11(日) 14:02:08
gitはUnicodeとか何も考えてないよ。パス名はバイト列として扱ってるだけだから。
でもWindowsのANSI APIは、パス名をローカライズされた文字列(日本ならcp932)とみなしてUnicodeに変換しちゃうから、
gitのやり方だとAscii文字列以外がおかしくなる。

Unicode APIを使ってくれれば問題は起きなくなるはずなんだが、
そのためにはgit側がパス名をUTF-16に変換してからAPIに渡す必要がある。
結局、Windowsではパス名は文字列であるという認識をgitが持ってくれないといけない。

よく知らないけどCygwin1.7はちゃんとこういう変換をやってるのかな。

29 :デフォルトの名無しさん:2010/04/11(日) 15:07:31
Unicodeとか何も考えてないのに、Unicodeに変換しちゃうの?

30 :デフォルトの名無しさん:2010/04/11(日) 15:09:28
この読解力の無さはすごい

31 :デフォルトの名無しさん:2010/04/11(日) 15:09:37
変換しちゃう、のは win32 API が、じゃないの?

32 :デフォルトの名無しさん:2010/04/11(日) 15:33:38
よくわからん。
gitが取得したパス名ってCP932と見なせるバイト列じゃないの?
WindowsのANSI APIが渡されたバイト列をCP932として評価するなら化けないと思うんだけど。

33 :デフォルトの名無しさん:2010/04/11(日) 15:37:10
>>28
この考え方のせいでgit(とhg)はクズなんだけど、
DVCSでは一番(と二番)使われてるから今更変更きかないんだろうな。
まったく残念だ。

34 :デフォルトの名無しさん:2010/04/11(日) 15:39:18
俺Unicodeライブラリなんか使わないけど、一度もファイル名が化けたことなんてないよ

35 :デフォルトの名無しさん:2010/04/11(日) 15:40:30
>>32
それはそうだな
「Unicodeに変換しちゃう」のなら、gitのレポジトリにはUnicodeで送るようなイメージを受ける
>>28が詳しいなら、もうちょっと補足して欲しい

36 :デフォルトの名無しさん:2010/04/11(日) 15:40:49
UTF-8なら日本語だろうがどうということはないのだがな・・・

37 :デフォルトの名無しさん:2010/04/11(日) 15:42:31
>>36
だから、WindowsのクライアントがUTF-8なりなんなりでgitレポジトリに
アクセスすれば済むって話だろ?なんでそんなこともできないんだろう。
Windowsクライアントの開発者はやる気ないの?

38 :デフォルトの名無しさん:2010/04/11(日) 15:44:10
1時間くらいソース見て、ちゃちゃっとパッチ書けるならいいんだが、
だとしたらきっともう誰かがやってるはずだから、そうはいかないん
だろうなぁ。

39 :デフォルトの名無しさん:2010/04/11(日) 15:45:08
>>37
え?gitはUnicodeのことなんて考えてないのに、リポジトリにはUnicodeで保存するの?

40 :デフォルトの名無しさん:2010/04/11(日) 15:49:59
Windowsクライアントってgit.exeのこと?

41 :デフォルトの名無しさん:2010/04/11(日) 15:54:53
>>32
ごめん考察足りてないな。
確かに日本語Windowsだけで使うなら、CP932のまま扱っても問題ないはずだけど、
実際上手く扱えないのは例によって\が含まれる文字の場合じゃないかと。

>>35
gitのリポジトリに保存されてるファイル名はバイト列がそのまま保存されてる。
変換するのは、リポジトリからファイル名を取り出して、APIに渡した後の話。


42 :デフォルトの名無しさん:2010/04/11(日) 15:55:38
>>40
msysgitとやらいうやつのことじゃね?

43 :デフォルトの名無しさん:2010/04/11(日) 15:55:47
まぁ理由は何であれ、事実上のデファクトスタンダードであるmsysgitで正しくフィル名を
扱えるようにならないと駄目だな。

44 :デフォルトの名無しさん:2010/04/11(日) 15:57:16
>>41
> 実際上手く扱えないのは例によって\が含まれる文字の場合じゃないかと。

実際使ってみればわかるけど、どんな日本語ファイル名でも、ファイル名全体が化けるよ。

45 :デフォルトの名無しさん:2010/04/11(日) 15:57:55
>>33
別に今からでも、Windowsの場合だけは、
パス名の内部表現をUTF-8の文字列にして、APIに渡す前にUTF-16に変換する
って動作をするように変えてくれれば、困る人はいないんじゃないかなぁ。

46 :デフォルトの名無しさん:2010/04/11(日) 15:59:22
>>39
>>37>>36へのレスで、UTF-8なら問題ないってのをまともに受けて書いたレス
その疑問は>>36へどうぞ

47 :デフォルトの名無しさん:2010/04/11(日) 15:59:39
ということは、msysgitがファイル名をUnicode(UTF-8?)でリポジトリに登録して、
持ってくるときはそれをcp932と見なして変換しちゃうということか。
どうやったらそんなタコなことできるんだよw

48 :デフォルトの名無しさん:2010/04/11(日) 16:11:13
>>47
おれぁファイル名のエンコードなんぞ知ったこっちゃねぇんだよ、
とかいってansi版のWinAPIにそのままバイト列突っ込んじまえば、そうなる。

49 :28:2010/04/11(日) 16:11:54
>>47
いやリポジトリにはあくまでバイト列としてしか登録されないからそんなことはしてないよ
ちょっと>>28は忘れてくれ…。
APIのUnicode変換と文字化けを関連付けたのはおかしかった。

50 :デフォルトの名無しさん:2010/04/11(日) 16:14:48
>>48
Unicodeライブラリを使わない場合、コマンドライン引数もファイル名取得もCP932なわけだが。

51 :デフォルトの名無しさん:2010/04/11(日) 16:17:15
ちょっと待て。
msysgitでファイルを登録して、msysgitでファイルを取得しても化けるということなのか?
それともUTF-8を使ってるUnix/Linuxで登録したものを取得したら化けるのか?

52 :デフォルトの名無しさん:2010/04/11(日) 16:17:17
>>50
リポジトリはUTF-8って前提だから化けるわけだよね。

53 :デフォルトの名無しさん:2010/04/11(日) 16:19:17
あとログも化けるw

54 :デフォルトの名無しさん:2010/04/11(日) 16:20:11
じゃ、Windowsに閉じたグループがmsysgit使うなら何の問題もないじゃん。

55 :デフォルトの名無しさん:2010/04/11(日) 16:24:22
>>54
>>51の後者だとは思うが、その上で、TortoiseGitでは0x5C混じりのファイル名で
コミット出来ないって問題があって、それはmsysgitをそのまま使ってるから云々って
問題があったような希ガス

今は直ってるのかも知れないけど、結局は同根の問題だと思う

56 :デフォルトの名無しさん:2010/04/11(日) 16:26:09
A系決めうちで使ってるコード全体をW系も使うようにするのは非常に手間だから誰もやってないと思う。

57 :デフォルトの名無しさん:2010/04/11(日) 16:27:49
やっとすっきりした。みんなサンクス。

58 :28:2010/04/11(日) 16:33:13
なんか適当な考察のせいで無駄にログ伸ばしたようで申し訳ない。
結局APIうんぬん以前にmsys側の問題が大きそうだね。


59 :デフォルトの名無しさん:2010/04/11(日) 16:42:14
誰か結論がどうなってんのかまとめてくれ

60 :デフォルトの名無しさん:2010/04/11(日) 16:44:51
>>59
・Windowsダサい
・gitで日本語ファイル名使う男の人って…
・結局cygwinってよくできてるよね

の三本立てでお送りしました

61 :デフォルトの名無しさん:2010/04/11(日) 17:01:58
結論:
・ファイル名がUTF-8で保存されているファイルはmsysgitを使うと化ける(いわゆる”日本語ファイル名”のみ)
・msysgitを使ってcp932のファイル名を保存する場合は\問題がある
・UTF-8でログを保存している場合は、mysgitでは化ける
・UTF-8版Cygwinでgitを使えば問題ない

62 :デフォルトの名無しさん:2010/04/11(日) 17:04:06
なんで日本語WindowsでUTF-8をデフォルトのコードページとして使えないの?
なんかそれだけで済む気がするんだけど、結局そういうOSじゃないってこと?
スレ違いかとは思うけど…

63 :デフォルトの名無しさん:2010/04/11(日) 17:04:40
>>60
そういうのは結論とはいわない。

>>61
ありがとう。よくわかった。

64 :デフォルトの名無しさん:2010/04/11(日) 17:08:18
>>62
カーネル内はUnicode化されてるんだけど、FAT32がcp932でファイル名を保存する関係で
ごちゃごちゃしてるんだと推察

65 :デフォルトの名無しさん:2010/04/11(日) 17:31:43
つか、日本語で名前付けるようなファイルって、結局は仕事で使うようなオフィス系のファイルだったり
デザイナーが使うリソースファイルだったりでしょ?
それらはどうせマージ出来ないんだから、gitとか使う意味ないし、そっちだけsvnなりでやってればいい。

66 :デフォルトの名無しさん:2010/04/11(日) 17:44:32
>>65
>>20まで戻る」

なんだこの不毛なスレ進行w

67 :デフォルトの名無しさん:2010/04/11(日) 18:07:21
さくらインターネットでgit入れてTortoiseGitでcloneとか
しようとしてるんだけどTortoisePlink passwordってダイアログが出て
パスワードを毎回入れるハメになるけど回避方法無いですか?

68 :デフォルトの名無しさん:2010/04/11(日) 18:41:32
まぁgitは一生マルチプラットホーム足り得ない田舎アプリってことでしょ
どうでもいい

69 :デフォルトの名無しさん:2010/04/11(日) 19:04:48
経緯の上でも、Linuxカーネル開発に使えれば十分なわけで。


70 :デフォルトの名無しさん:2010/04/11(日) 19:47:06
>>67
sshの公開鍵を作ればいい。
TortoiseSVNのほうが情報充実してるから、
TortoiseSVN ssh 公開鍵 あたりのキーワードでぐぐる。

71 :デフォルトの名無しさん:2010/04/11(日) 19:56:55
>>68
Windowsがサポートされればマルチプラットホームなのか?
どうしてだかドザって除け者にされると激しい反応を示すよな。。。。

72 :デフォルトの名無しさん:2010/04/11(日) 20:00:58
>>70
サンクス。sshの公開鍵ね
ぐぐって試してみるわ〜

73 :デフォルトの名無しさん:2010/04/11(日) 20:26:14
>>71
なんだこの馬鹿は
なぜ突然「Windowsがサポートされればマルチプラットホーム」とか言い出すんだ?
マルチプラットフォームの意味知らんのか?
そんなの成り立つわけが無いだろ

74 :デフォルトの名無しさん:2010/04/11(日) 21:00:34
いや、まあ、あれだ

Windows入れてもすでにほぼマルチプラットフォームなんだ、gitは
ただ、マルチバイト文字圏ってのはなんだかんだ自助努力が必要なんだ結局
そこのところ、開発者かユーザかどっちがひっかぶるかってだけの話なんだと思うんだ
今世紀も半ばくらいには、多分解消してるよ。主にWindowsの変化によって(笑)

75 :デフォルトの名無しさん:2010/04/11(日) 21:01:35
>>73
は? Windowsでgitのファイル名が化けるだとかって、昨日からずーっとグダグダやってんじゃん。
Windowsでうまく動かないから田舎アプリだとか、痛いレスしちゃって。

76 :デフォルトの名無しさん:2010/04/11(日) 21:09:19
一部を除いては、も少し建設的な情報交換もできたと思うので、そのまとめはどうかと

77 :デフォルトの名無しさん:2010/04/11(日) 21:15:58
Windows?そんなの知るかよ!って奴等が集まってるようには、見えるなw
http://repo.or.cz/w/git.git

78 :デフォルトの名無しさん:2010/04/11(日) 21:26:25
no-windows wwwww

79 :デフォルトの名無しさん:2010/04/11(日) 21:49:16
>>77
当たり前だけどJunio C Hamano氏の活動量すげぇ

80 :デフォルトの名無しさん:2010/04/11(日) 22:03:52
世界の70%を占めてるOSにまともに対応せずにマルチプラットホームとか(笑)
ごく簡単に対応できる問題にも対応できずに高スキル集団気取ってんなよgit共がww

81 :デフォルトの名無しさん:2010/04/11(日) 22:13:00
>>70
できた。puttygenで生成したテキストをauthorized_keysというファイル名で
保存しサーバーの$HOME/.sshのフォルダにアップロードするという事が
分からず時間掛かったけど。
あとはpageantを常駐してadd keyさせたらパス入力聞いてこなくなった。

82 :デフォルトの名無しさん:2010/04/11(日) 22:17:49
確かに変なのが居着いてるな
Windowsで普通にgit使いたい奴にとって非常に迷惑な奴が

83 :デフォルトの名無しさん:2010/04/11(日) 22:51:26
>>80
WindowsならSVNを使えばいいんじゃないですかね?
無理してgit使ってWindowsの欠点に文句言うのも不毛だよね

84 :デフォルトの名無しさん:2010/04/11(日) 22:58:20
Windowsの文字コードをUTF8にしたいんだけどどうやるの?

85 :デフォルトの名無しさん:2010/04/11(日) 23:00:55
文字列をバイト列と考えるgit側の致命的欠陥だろ
どこの誰がパスをバイト列で指定するんだよ
根本から間違ってる

86 :デフォルトの名無しさん:2010/04/11(日) 23:02:14
リナ糞圏のマルチバイトの弱さは特筆に価する。

87 :デフォルトの名無しさん:2010/04/11(日) 23:06:27
>>80
世界の70%を占めてるOSの世界の70%を占めてるユーザーで問題が無いことが問題なんだな。
(細かい数字は適当だから気にするな)

88 :デフォルトの名無しさん:2010/04/11(日) 23:09:33
>>85
だったらwinユーザーはgit使わずsvn使えば問題ない

89 :デフォルトの名無しさん:2010/04/11(日) 23:10:46
べつにWindowsユーザーに使ってもらうために作ってるわけでもないだろうし。


90 :デフォルトの名無しさん:2010/04/11(日) 23:10:48
>>88
なら田舎アプリと言われたからってウダウダ口出しすんな

91 :デフォルトの名無しさん:2010/04/11(日) 23:12:03
LinuxのlocaleをEUC-JPにするとかShift-JISにするとかすれば同じ問題が起きる
Windowsのlocaleを英語にすれば(ほぼ)問題が解決する
それが問題なのか問題では無いのかの違い

92 :デフォルトの名無しさん:2010/04/11(日) 23:12:32
というかWindowsだと問題が多発するgitをわざわざ使う必要なし
Windowsならsvn使うのが超安定

93 :デフォルトの名無しさん:2010/04/11(日) 23:19:34
>>90
そんなにくやしいなら自分でWindows用のgit作れ
オープンソースなんだからさ

94 :デフォルトの名無しさん:2010/04/11(日) 23:21:07
そろそろ、日本語使うなら Bazaar 使おうぜ! って言ってもいい?

95 :デフォルトの名無しさん:2010/04/12(月) 00:55:49
gitとかそろそろ滅びろよ

96 :デフォルトの名無しさん:2010/04/12(月) 01:07:10
svn使ってれば?

97 :デフォルトの名無しさん:2010/04/12(月) 02:02:12
>>94
【bzr】Bazaarでバージョン管理 Rev 2
http://pc12.2ch.net/test/read.cgi/tech/1265951333/

Bazaarって知らなかったけど面白そうだな

98 :デフォルトの名無しさん:2010/04/12(月) 10:24:45
cygwin の git で LANG=ja_JP.utf-8 で使うというのが
現状では一番なのではないのか?
どうしてもmsysgitを使いたいっていうのならパッチ当てるしか...

99 :デフォルトの名無しさん:2010/04/12(月) 15:52:23
まっ良く知らない奴がWindowsでgit使うと痛い目見るって事だな

ここ見た奴は周りがWinでgit使いたいって言ったら全力で引き止めろよ

100 :デフォルトの名無しさん:2010/04/12(月) 17:47:41
いつもこの過剰な流れを見るたびに日本語ファイル名を使わなきゃ良いだけだろと思うんだけど...
ログはlogoutputencodingとcommitencodingを設定すれば問題ないし。

101 :デフォルトの名無しさん:2010/04/12(月) 18:02:23
まあ、その辺りは、置かれてる立場によって変わってくるだろ。
一人だけでやってるならなんとでもなるが。

102 :デフォルトの名無しさん:2010/04/12(月) 19:32:05
gitのコミッタはいい加減ガキ臭すぎると思うわ
簡単に解決できる問題をwindows憎しと言う感情のみで放置
チョン国人と同レベル過ぎる

103 :デフォルトの名無しさん:2010/04/12(月) 19:34:40
他人の感情がわかるとか凄いエスパーだな

104 :デフォルトの名無しさん:2010/04/12(月) 19:42:04
>>77 見ればただの野次馬な俺でも分かるってばよ・・・

105 :デフォルトの名無しさん:2010/04/12(月) 19:42:36
>>102
君みたいな人はSubversion使うのが合ってると思うよ
Windowsの文字コードの欠点はどうしようも無いからね

106 :デフォルトの名無しさん:2010/04/12(月) 20:04:28
あれ、svnでは解決してるんだろ?
どうしようも無いことなの?

107 :デフォルトの名無しさん:2010/04/12(月) 20:10:40
>>106
Linuxカーネル開発する上で困ることがないのでスルー。


108 :デフォルトの名無しさん:2010/04/12(月) 20:20:24
他の殆どのマルチプラットホームを謳うアプリで文字コードの問題を解決しているのに
git界隈ではどうしようもないと言われている
つまりはそういう事だ

109 :デフォルトの名無しさん:2010/04/12(月) 20:24:36
まぁ、現実問題対応していないと言う事は、gitはコミュニティレベルで劣っていると言う事の証左だよね。

110 :デフォルトの名無しさん:2010/04/12(月) 20:59:37
盛り上がっているのでmsysgitのソースコード見てみた。fopenとか使っている
んだな。gdi++.dllみたいにフックしてUTF-8変換すれば良いんじゃない?

111 :デフォルトの名無しさん:2010/04/12(月) 22:20:21
まあMercurialで問題ないわけだしね

112 :デフォルトの名無しさん:2010/04/12(月) 22:53:00
あるわ

113 :デフォルトの名無しさん:2010/04/12(月) 22:54:53
Hg、なんか中途半端なんだよな
いろんな意味で

114 :デフォルトの名無しさん:2010/04/12(月) 23:11:50
そうなのか?

115 :デフォルトの名無しさん:2010/04/12(月) 23:31:22
金属光沢だから、固体かと思ったら液体だった、みたいな?

116 :デフォルトの名無しさん:2010/04/12(月) 23:40:29
文字化けと言う失笑物の欠陥を直せないでいるgitよりはマシだけどね。

117 :デフォルトの名無しさん:2010/04/12(月) 23:47:45
自分が失笑されてることにも気づけないのか

118 :デフォルトの名無しさん:2010/04/13(火) 00:52:09
>>117
gitは検索タグがno-windowsってくらいだから、気づけないっていうか見ざる聞かざるだね

119 :デフォルトの名無しさん:2010/04/13(火) 01:31:06
プラットフォーム間で文字化けすると言う、普通に考えて恥ずかしいレベルの初歩的欠陥も

相手方がWindowsとなると途端に俺らに関係ねーししらねーよとなる

なんと言う低い民度のコミュニティであろうか

あらゆる原動力がwindows憎し、svn憎しから始まってるから、これで妥当なんだろうけどな

120 :デフォルトの名無しさん:2010/04/13(火) 02:52:26
根暗が負の感情を原動力にした時に発揮する力は半端無いからな

121 :デフォルトの名無しさん:2010/04/13(火) 03:34:21
別に憎いとかじゃなくて、彼らからみれば普通に馴染みのないOSだから。
そうやってギャーギャー言われると、こっち見んなってのはあるだろうけど。

122 :デフォルトの名無しさん:2010/04/13(火) 04:15:55
馴染みが無いと来たかw
それで居て田舎と言われると怒り出すww

123 :デフォルトの名無しさん:2010/04/13(火) 04:30:27
相手してもらえないからってファビョりすぎ。自称「都会」のWindowsで遊んでなさいよ。

124 :デフォルトの名無しさん:2010/04/13(火) 04:56:39
と、こんな時間に律儀に相手をしてる奴が何か言ってます。

125 :デフォルトの名無しさん:2010/04/13(火) 07:48:41
>>111
Mercurialも同じ問題抱えてた気が……

126 :デフォルトの名無しさん:2010/04/13(火) 08:25:22
Mercurialはmsys依存してるわけじゃないから、まだ何とかする余地がありそうなんだけど。

127 :デフォルトの名無しさん:2010/04/13(火) 10:35:15
Windows だけじゃなくて Mac に持ってっても問題出るよなぁ


128 :デフォルトの名無しさん:2010/04/13(火) 13:00:29
LANG=ja_JP.EUC-JPとかでもダメ。
要するに、汎用性は目標じゃないので、
多言語化はしたくない、ってことだろ。

現実を見据えた完全性を目標にしてる
感じのsvnやbzrとはもはや比較できない。


129 :デフォルトの名無しさん:2010/04/13(火) 13:19:27
もともとはLinus Torvaldsのオレ専用バージョン管理システムなんだから、
「Windowsで使えねー」とか言っても「Windowsを使うな」ってなるのは
ある意味当然

しかもLinusは特段優れたソフトウェアアーキテクトでもないしw

130 :デフォルトの名無しさん:2010/04/13(火) 13:46:58
誤解が無いように言っておくとWindowsで問題があるわけじゃない
変にローカライズされた一部のWindowsで問題がある
その中に日本語版Windowsが含まれるということ

131 :デフォルトの名無しさん:2010/04/13(火) 14:41:03
その「一部」の分母が数千万以上ってだけなんですけどね。

132 :デフォルトの名無しさん:2010/04/13(火) 16:07:08
それ以上に英語圏の分母が大きければ取るに足らんと思われても仕方ない

133 :デフォルトの名無しさん:2010/04/13(火) 18:32:41
その「一部」って世界のLinuxの稼動数超えてるよねw

134 :デフォルトの名無しさん:2010/04/13(火) 19:06:53
微妙な言い方だな。
Windows と Linux の「稼動数」の差って「ユーザ数」の差より小さいんじゃね?

135 :デフォルトの名無しさん:2010/04/13(火) 19:21:01
問題はOS自体の稼働数じゃなくてその上でのgitの稼働数だとおも。


136 :デフォルトの名無しさん:2010/04/13(火) 19:37:00
え?gitをまともに使えない現状でのgit稼動数を問題にするの?w
そりゃ一生解決しませんわw

137 :デフォルトの名無しさん:2010/04/13(火) 19:39:30
svnみたいに高品質ならwindowsでも使われまくるよ

138 :デフォルトの名無しさん:2010/04/13(火) 19:42:11
次にお前は だったらwinユーザーはgit使わずsvn使えば問題ない と言う

139 :デフォルトの名無しさん:2010/04/13(火) 20:27:30
なんかgitのこと叩いてるWindowsユーザって、ふだん高飛車でちやほやされてるご令嬢が
転校生の主人公に無視されて「わたくしを誰だと思っているの!?」って怒ってるみたいでちょっと萌えるw

140 :デフォルトの名無しさん:2010/04/13(火) 20:44:05
>>139
いや、別にGitを使わなくてすむならそれでいいんだけど、
開発者のあいだでGitが人気なのはもはや止めようがなく、
好き嫌いに関わらず、使わなきゃいけない場面というのは
どうしても出てくるわけよ。
そして、Windowsで使おうとすると問題がでて困る、という話。
自分にすべて決定権があるならGit使わないという決定が
できるけど、そうじゃない人もいるよね。残念ながら。

141 :デフォルトの名無しさん:2010/04/13(火) 20:54:14
うそーん。
git使ってる人達は問題のない使い方してるはずだから、
Windowsで使うと問題が起こるなんてことはないんだよー。

142 :デフォルトの名無しさん:2010/04/13(火) 21:00:55
>>141
× 問題のない使い方
○ 問題に近寄らない使い方

143 :デフォルトの名無しさん:2010/04/13(火) 22:47:08
>>125
Mercurialはダメ文字は大丈夫。でもファイル名がバイナリ列なのはgitと同じ。

144 :デフォルトの名無しさん:2010/04/13(火) 23:59:13
あー、ダメ文字って0x5c入りの奴もそう呼ぶんだ。
マッピングできない奴だけを言うのかと思ってた。

145 :デフォルトの名無しさん:2010/04/14(水) 04:17:45
Git使いの>>139は物語の主人公らしいw
流石ですw

146 :デフォルトの名無しさん:2010/04/14(水) 10:45:47
>>144
個人的には、5Chが入ってる文字=ダメ文字、で使ってきたから
マッピングできない文字をダメ文字と呼ぶ方が新鮮だったり。

147 :デフォルトの名無しさん:2010/04/14(水) 12:31:34
>>143
fixutf8

148 :デフォルトの名無しさん:2010/04/14(水) 13:18:49
バージョン管理システムも用途によって分化していくのかな。

149 :デフォルトの名無しさん:2010/04/14(水) 15:47:58
>>147
Hgスレだとfixutf8でもだめっぽいけど

150 :デフォルトの名無しさん:2010/04/14(水) 20:50:16
まぁgitもMercurialもLinux kernelの管理用に作られたわけだしな

151 :デフォルトの名無しさん:2010/04/14(水) 21:00:01
というかそういうWindowsでしか発生しない問題なんかは
TortoiseXXXとかのGUIがなんとかすればいいだけじゃないか?
どうせWindowsでコマンドラインから使ってる奴なんて
ほとんどいないでしょ
もしコマンドラインからやりたいならCygwin使えばいいだけだし

152 :デフォルトの名無しさん:2010/04/14(水) 22:10:53
>>151
MergurialやGitの問題です

153 :デフォルトの名無しさん:2010/04/14(水) 23:27:14
>>149
fixutf8でファイル名の問題は解決する

154 :デフォルトの名無しさん:2010/04/15(木) 00:08:27
>>151
無知と偏見の塊なのを自覚して黙ってた方が良いよ

155 :デフォルトの名無しさん:2010/04/15(木) 01:23:15
最近、仕事先でgitを使ってる。
一つ不満なのが、git status やらで出てくるメッセージが英語なんだが、
これって日本語メッセージにできないの?linuxのCUIでの話。
警告とか普通に読み飛ばしてしまってなんだかなー

export LANG=ja_JP.utf-8 とかはやってみた。だめだった。
なんかパッチとか必要なのかな

156 :デフォルトの名無しさん:2010/04/15(木) 01:32:15
>>155
ソースコードをgettext化する必要があるだろうね。
gitの配布物の中にある git gui はこれを使ってそこそこ国際化済み。


157 :155:2010/04/15(木) 01:39:31
>>156
CUIはまだ国際化されてないのね
thx

158 :デフォルトの名無しさん:2010/04/19(月) 14:19:22
WindowsはさっさとUTF8化しる!
いつまでSJISなんだよ古くさー

159 :デフォルトの名無しさん:2010/04/19(月) 15:42:28
えっ

160 :デフォルトの名無しさん:2010/04/19(月) 20:38:21
マジで言ってるの?

161 :デフォルトの名無しさん:2010/04/20(火) 16:54:26
3.1の話かとw

162 :デフォルトの名無しさん:2010/04/20(火) 19:50:36
158じゃないけど、エクスプローラとか
コマンドラインとかのフロントエンドは
もうUTF-8にしないのかなーとは思う。


163 :デフォルトの名無しさん:2010/04/20(火) 21:21:46
コマンドプロンプト自体は一応UTF-8対応してるぞ

164 :デフォルトの名無しさん:2010/04/20(火) 22:13:55
Windowsの標準アプリはほぼUnicode対応になってるはず。
CP932に依存するのってコマンドプロンプトくらいじゃないか?

標準じゃないやつだと未だにAnsi API使ってるのがいっぱいあるけどな。

165 :デフォルトの名無しさん:2010/04/20(火) 22:58:11
cmd.exe のコードページを utf-8 にするには
chcp 65001
としたらよいのだが、今度は日本語フォントが。

166 :デフォルトの名無しさん:2010/04/20(火) 23:26:07
>>164
甘いよ。大甘。

Windowsではメニューやダイアログボックスなどのリソースは実行形式に埋め込まれるが、
そのリソースはUTF8どころか、UNICODEですら記述されていない。

なのでOSのロケールをUTF8にしてもまともに表示できるアプリはほとんどない。

167 :デフォルトの名無しさん:2010/04/20(火) 23:32:54
>>166
???

168 :デフォルトの名無しさん:2010/04/20(火) 23:36:57
ここまで意味不明な文章もなかなかないな

169 :デフォルトの名無しさん:2010/04/20(火) 23:49:49
なんだ、ム板だからわかるかと思ったが、このスレの住人にはわからんのか。

いや、悪かったな。意味不明な文章書いて。忘れてくれ。

170 :デフォルトの名無しさん:2010/04/21(水) 00:32:52
これはひどい。

171 :デフォルトの名無しさん:2010/04/21(水) 00:36:44
explorer.exeなりをバイナリエディタで開いてみれば、リソースがUnicodeで入ってることくらいすぐわかるんだが…。
(ただしVista以降ではリソースDLLに分離されてる)

172 :デフォルトの名無しさん:2010/04/21(水) 00:50:30
notepad.exe の保存ダイアログでは文字コードの指定ができ、utf-8 もある。
メモ帳で utf-8 を表示できるだろうということは標準コントロールで表示できることを示唆している。

173 :デフォルトの名無しさん:2010/04/21(水) 01:07:23
>>172
それはファイルの読み書きするときに変換かけてるだけだ。
EditコントロールはUTF-16でしか動かないぞ。


174 :デフォルトの名無しさん:2010/04/21(水) 08:56:15
そもそも>>162のexplorerがUTF-8に対応するってどういう意味かわからん
NTFSがUTF-8化するってこと?

175 :デフォルトの名無しさん:2010/04/21(水) 15:31:19
文字コード気にするやつはWindowsでgitを使うな
超安定のSubversionを使ってればいいんだよ
Windowsはもう諦めろ。無理してgit導入しても周りの迷惑にしかならん

176 :デフォルトの名無しさん:2010/04/21(水) 15:52:08
VisualStudioのリソースエディタでUnicodeが扱えないだけ

177 :デフォルトの名無しさん:2010/04/21(水) 16:48:06
はぁ?

178 :デフォルトの名無しさん:2010/04/21(水) 20:36:16
ファイル名に日本語使うバカは常識的に居ないからgit使っても問題なし

179 :デフォルトの名無しさん:2010/04/21(水) 20:42:37
はぁ?

180 :デフォルトの名無しさん:2010/04/21(水) 20:56:18
ホームフォルダが日本語名になっちゃってる人はよく見かける

181 :デフォルトの名無しさん:2010/04/21(水) 21:12:03
フォルダ()笑て何ですか?

182 :デフォルトの名無しさん:2010/04/21(水) 21:16:33
>>181
Windowsで使うな!と言いたいんだな?


183 :デフォルトの名無しさん:2010/04/21(水) 22:11:34
これだからWindowsユーザーは…
Subversionしか勧められないわけだ


184 :デフォルトの名無しさん:2010/04/21(水) 22:16:07
Windowsは今のunicodeの実装自体にはそれほど問題無い。Macよりは。
ただ過去の無理矢理localizeの後遺症がデカい。

185 :デフォルトの名無しさん:2010/04/21(水) 22:24:32
今時どのOSだってフォルダと言う

186 :デフォルトの名無しさん:2010/04/21(水) 22:37:48
フォルダとディレクトリは必ずしも一致しないな

187 :デフォルトの名無しさん:2010/04/22(木) 07:54:57
Windowsとかどうでもいいので開発陣には他のことに力を注いでもらいたい

188 :デフォルトの名無しさん:2010/04/22(木) 08:21:29
果たしてwinだけの問題であろうか。
ファイル名を単なるバイト列としか扱ってないことを続けて良いのか。

189 :デフォルトの名無しさん:2010/04/22(木) 09:09:48
Linux含めてUnixのfilesystemはバイト列で扱ってるからな。
WindowsはfilesystemはUnicodeとして扱う。

190 :デフォルトの名無しさん:2010/04/22(木) 15:58:08
MicrosoftがCanonical(Ubuntuの開発元)の運営するLaunchpadを使い始めた件。
https://launchpad.net/coapp
https://launchpad.net/~garretts
おまけ
https://bugs.launchpad.net/bugs/1

191 :デフォルトの名無しさん:2010/04/22(木) 20:38:02
>Unixのfilesystemはバイト列で扱ってる
じゃあどうしようもないな

192 :デフォルトの名無しさん:2010/04/23(金) 23:13:57
>>190
MSの歩み寄りに今だに感情的に反発してる馬鹿共は何なの
どこまでガキなの

193 :デフォルトの名無しさん:2010/04/24(土) 02:20:51
>>189
そういう現状に即さない田舎OSは勘弁して欲しいな。
ファイル名がバイト列で良いならテキストファイルもバイト列として扱えるはずって事になる。
これがどれだけ無知で間抜けで短絡的かは言うまでもない。

194 :デフォルトの名無しさん:2010/04/24(土) 02:42:49
Windowsとかパソコンに弱い初心者向けだからgitとかは対応しなくていいよ
それにWinならSubversionがあるしな

195 :デフォルトの名無しさん:2010/04/24(土) 02:43:38
× 言うまでもない
○ 俺はバカだから説明できないが絶対正しいに決まってる

196 :デフォルトの名無しさん:2010/04/24(土) 03:38:05
>>195
それは流石に苦しいぞw

197 :デフォルトの名無しさん:2010/04/24(土) 04:02:01
gitのマルチバイト問題はUTF-8 cygwinでイケル!かと思いきや、
git-guiやgitkが文字化けしたり、文字化けしたのはファイル指定でエラーおこしたり散々w
コマンドラインで使う分には問題ないんだがなあ。


githubもマルチバイトファイル名のファイルつっこむとファイルリストからクリックして見られなかったり、
たまにサーバーエラー起こすしw
githubにはエラーでたページからレポートしてるんだけどなかなか直してくれない。
github自身のissue トラッカーってないの?

198 :デフォルトの名無しさん:2010/04/24(土) 04:52:54
winユーザーがgit使えなくて嫉妬するスレになってるな
問題沢山あるからgit使うのはやめとけ

199 :デフォルトの名無しさん:2010/04/24(土) 05:12:27
文字コードにまともに対応できない無能集団が>>194見たいな事言っちゃってる姿がウザいんだよ

200 :デフォルトの名無しさん:2010/04/24(土) 07:18:42
まあ全世界から見たら「日本語の」「windows」なんて
田舎環境を使っている方が悪いんだよ


201 :デフォルトの名無しさん:2010/04/24(土) 08:07:41
果たしてwinだけの問題であろうか。
ファイル名を単なるバイト列としか扱ってないことを続けて良いのか。


202 :デフォルトの名無しさん:2010/04/24(土) 08:11:44
>>201
それは、そもそも、このスレで取り上げる主旨じゃない→スレ違い。

203 :デフォルトの名無しさん:2010/04/24(土) 08:18:00
>>200
「日本語の」だと?
馬鹿も大概にしろ

204 :デフォルトの名無しさん:2010/04/24(土) 13:36:49
>>200
馬鹿現るw

205 :デフォルトの名無しさん:2010/04/24(土) 14:14:57
英語以外はみんな問題あるだろ。
でも変換なしにがしがし書ける英語っていいよな。

206 :デフォルトの名無しさん:2010/04/24(土) 15:20:28
問題はおまいらだ

207 :デフォルトの名無しさん:2010/04/24(土) 18:15:20
winでgit使いたいなら使えばいいんだよ
ただ日本語のファイル名付けるバカで低脳な奴はSubversionにしとけ
日本語名付けるやつほど迷惑な奴もいないよな

208 :デフォルトの名無しさん:2010/04/24(土) 18:23:50
日本語ファイル名が馬鹿で低脳かは、TPOによるだろ。
米国人主体でプログラム開発してるなら、日本語ファイル名なんて論外だろうけど、
日本人主体のプロジェクトで、プログラマ以外のスタッフの方が多い
ゲームとか書籍製作で使うなら、日本語ファイル名禁止なんていうほうが論外だし。
そういうこと考えずに自分の狭い視野だけで低脳と決め付けるほうが低脳。


209 :デフォルトの名無しさん:2010/04/24(土) 19:05:31
別に日本語のファイル名つけても問題ないけど…
ただWindowsでおかしいだけでしょ?

210 :デフォルトの名無しさん:2010/04/24(土) 19:34:49
いい加減うざいんだが

211 :デフォルトの名無しさん:2010/04/24(土) 21:05:17
正直ドキュメントは、怪しい英語より日本語ファイル名を的確につけて欲しい
そんなものをgitに放り込むなってのは正しいんだろうが、gitとsvnの両用ってのも無駄に感じる
要はそんなとこだろ
なんでそんなにマルチバイト対応が後回しになるんだろってのは気になるな

212 :デフォルトの名無しさん:2010/04/24(土) 21:54:01
そりゃ単にファイル名を人間が読み取る文字列だと思ってないからでは。

213 :デフォルトの名無しさん:2010/04/25(日) 01:26:28
ここ見てると、一般にユーザーにバージョン管理の機能を落とし込んだDropboxがまさに対照的でおもしろいな。
馬鹿でも使えてTortoiseSVNよりももっと簡単(機能は少ないけど)
サーバー自前で立てる必要もない(むしろLAN用に立てさせろてほしいが)
Python利用のクライアントだがWindowsでも日本語ファイル名もOK。

IDとパスのみでネットのストレージにおくからと情報漏えいが不安な人にも暗号化ドライブ作成のTrueCryptとの併用で安心。
Dropboxはバイナリは差分とって送信するので数百MBの暗号化イメージ作って、
その中の1ファイルを更新しても軽やかに同期とられる。
コンフリクトは知らんがw

見た目はファイル共有の側面が強いが、開発者インタビューではバージョン管理をもっと手軽に
(多分このスレでは相手にしてないデザイナさんや事務職の人相手にも)ってのを売りだといってたよ。

214 :デフォルトの名無しさん:2010/04/25(日) 01:35:53
DropboxとSubversionを比較するのが間違い

215 :デフォルトの名無しさん:2010/04/25(日) 03:45:30
>>208
「日本語ファイル名禁止なんていうほうが論外」なんて言うのも低脳だな
日本語ファイル名を付ける可能性があるならgitなんて使わせないのが正解

問題が起こる可能性があるのを説明も出来ないのかお前は
説明したのに使う事になってるならそんな馬鹿な奴らほっとけ

216 :デフォルトの名無しさん:2010/04/25(日) 03:51:35
>>215
馬鹿はお前
gitが直せば良いだけの話に何を言ってるんだ?

217 :デフォルトの名無しさん:2010/04/25(日) 05:31:08
・〇〇という奴はバカで低脳
・〇〇なんて論外

そろそろ、釣られる奴は低脳くらいいってもいいころあい

218 :デフォルトの名無しさん:2010/04/25(日) 08:53:23
結論出ない議論を繰り返すよりgitでfilepathをUnicodeに変換して保存するコードを書いた方が建設的だわな
本家で受け入れられなくてもforkすればいいだけだし

219 :デフォルトの名無しさん:2010/04/25(日) 08:54:23
>>215
>日本語ファイル名を付ける可能性があるならgitなんて使わせないのが正解
いや、
>日本語ファイル名禁止なんていうほうが論外
は、ほぼそういう意味で書いたんだが。
なんか勘違いしてね?



220 :デフォルトの名無しさん:2010/04/25(日) 10:20:30
バカに正常な読解力を期待するからこうなるのだ。

221 :デフォルトの名無しさん:2010/04/25(日) 10:52:09
>>213
RCSならリポジトリも作らずにその場で今の状態を取っとけるじゃん
自分は今でもたまに使ってる

222 :デフォルトの名無しさん:2010/04/25(日) 10:56:09
Windowsとかよく知らないし

223 :デフォルトの名無しさん:2010/04/25(日) 13:30:20
Linuxとかよく知らないし

224 :デフォルトの名無しさん:2010/04/25(日) 13:40:51
わかった。

Q. git で日本語ファイル名が使えません。

に対して、

A1. 日本語ファイル名を使いたいなら Subversion とかの他の VCS を使え派



A2. git が日本語ファイル名に対応しろ派



A3. 日本語ファイル名を使うな派

がいるのな。



225 :デフォルトの名無しさん:2010/04/25(日) 13:43:10
Unicodeとかよく知らないし

226 :デフォルトの名無しさん:2010/04/25(日) 13:46:48
日本語とかよく知らないし

227 :デフォルトの名無しさん:2010/04/25(日) 13:52:52
>>224
× Q. git で日本語ファイル名が使えません。
○ Q. Windowsでgitを使うと日本語ファイル名が使えません。

228 :デフォルトの名無しさん:2010/04/25(日) 15:43:39
× Q. git で日本語ファイル名が使えません。
× Q. Windowsでgitを使うと日本語ファイル名が使えません。
○ Q. Windows-Linux間でgitを使うと日本語ファイル名が化けます。

229 :デフォルトの名無しさん:2010/04/25(日) 17:01:24
問題なのはwinでgitを使いたいと思ってる奴がこのスレに来てる事
win用じゃないんだから諦めてsvn使いなよ
gitに執着してるようだけど馬鹿みたいだよ?

230 :デフォルトの名無しさん:2010/04/25(日) 17:24:01
>>229
>問題なのはwinでgitを使いたいと思ってる奴がこのスレに来てる事
え?何で問題なの?理由は?

231 :デフォルトの名無しさん:2010/04/25(日) 17:25:00
自分も含めたグループに使わせたい場合とか考えないんだろうな。
自分のことしか考えてないか、一人でしか仕事してないか。

232 :デフォルトの名無しさん:2010/04/25(日) 17:26:32
そもそも仕事したことが無いんだと思うよ

233 :デフォルトの名無しさん:2010/04/25(日) 18:03:02
gitスレはLinux板にあるってのもなw

234 :デフォルトの名無しさん:2010/04/25(日) 18:12:52
OSSに関わってたり、Windowsを開発機にしてUnix鯖のwebアプリ作ってたりするとそうもいかない。
今時「win用じゃないんだから」はナンセンスじゃないか?
まー、Unix鯖で動くアプリ作るときは結局仮想マシンつかうし、その上でgit動かす分には問題ないかw

235 :デフォルトの名無しさん:2010/04/25(日) 18:38:57
なんのためにgitが生まれたか知らずに語っている奴が混じってないか?


236 :デフォルトの名無しさん:2010/04/25(日) 18:45:22
つまりMercurialも同様ということだな

237 :デフォルトの名無しさん:2010/04/25(日) 20:58:17
>>231
他人の事を考えるならgitなんか使うな
それこそSubversion使うだろ普通

238 :デフォルトの名無しさん:2010/04/25(日) 21:28:38
どんな普通だよw

239 :デフォルトの名無しさん:2010/04/25(日) 21:29:56
でもさー、日本語ファイル名使うようなファイルってWordとかExcelみたいな、
そのへんのバージョン管理システムのdiffサブコマンドじゃーどうにもならない
ファイルばっかりだし、それこそファイル名に日付でも付けた状態でそのまま
ファイルサーバに置いて管理して欲しいと思う……

どーせMS Officeってファイル内部で変更履歴管理できるのばっかりだろうし。

あ、プログラムのファイル名に日本語使う人は死んでいいから。

240 :デフォルトの名無しさん:2010/04/25(日) 21:31:44
マルチプラットフォームで日本語ファイル名も使うプロジェクト、
という前提での「普通」だろ?

241 :デフォルトの名無しさん:2010/04/25(日) 21:48:26
そういうプロジェクトでgitを使ってはいけない理由って別にないよね。

結局、gitは日本語ファイル名がうまく扱えないという現実を
「不具合だから直すべき」ととらえる人と、
「そういう風になっているソフトでわざわざ想定外の使い方をしなきゃいいのに」
と思ってるひととでは永久に相容れないと思う。

242 :デフォルトの名無しさん:2010/04/25(日) 23:12:55
>>239
>あ、プログラムのファイル名に日本語使う人は死んでいいから。
業務プログラムのテストケースとかだと普通にあるけどな。
"要件XXX-価格決定-特定得意先別値引率適用Test" みたいな。

243 :デフォルトの名無しさん:2010/04/25(日) 23:47:17
>結局、gitは日本語ファイル名がうまく扱えないという現実を
日本語Windowsでの話だろそれ。自分の環境を前提に何でも話通そうとするなよ。

244 :デフォルトの名無しさん:2010/04/25(日) 23:56:00
>>224
× git が日本語ファイル名に対応しろ派
○ git を日本語ファイル名に対応させろ派

245 :デフォルトの名無しさん:2010/04/26(月) 01:09:39
つまり、要約すると、早い話が、gitは国際化対応できないって事で、FA?

246 :デフォルトの名無しさん:2010/04/26(月) 01:13:08
日本語をgitに対応させろ派も旗揚げ

247 :デフォルトの名無しさん:2010/04/26(月) 01:24:25
だからgitは世界のシェアの2%のLinuxの、そのまた更にシングルバイト圏でしか使う事ができない田舎アプリなんだよ
もう何も期待すんなよ

248 :デフォルトの名無しさん:2010/04/26(月) 01:30:12
gitのWindowsでの日本語ファイル名問題だけでここまで引っ張るのはすごい

>>247
シェア高いのって何?やっぱりSVNやCVSなのかな

249 :デフォルトの名無しさん:2010/04/26(月) 02:36:54
gitすげーさいこーっていう流れの反動と、svnみたいに簡単に
使えないことへのがっかり感とが怨念っぽくなってるんだろ

250 :デフォルトの名無しさん:2010/04/26(月) 03:56:16
>>249
まあ、バージョン管理システムて基本大勢で使う為の物になってしまったから、
バージョン管理システム自体の「癖」を気にしながら使わなきゃなのわ。
ちょと、辛いよね。

251 :デフォルトの名無しさん:2010/04/26(月) 04:13:17
問題はgitユーザーがとにかくSVN等を馬鹿にしていて
SVNがWindowsや文字コードに完全対応している事すら何故か見下し馬鹿にすると言う意味不明な行動を取っている事じゃなかろうか。

gitユーザーが最初に怨念染みたネガ波動を全方位に振りまいてんだから、それがそっくりそのまま帰ってきてもあたり前だろうに。

252 :デフォルトの名無しさん:2010/04/26(月) 05:57:16
gitスゲー他のvcsは全部糞git最強とか繰り返してるのを見てwktkしながらgitを試してみたら

導入第一歩であっけなく文字化け

それはもう遣る瀬無い気持ちになったとさ

253 :デフォルトの名無しさん:2010/04/26(月) 07:36:07
>>224
gitもSubversionもどうでもよくて、煽り合いたいだけの奴らが少なからず混じってるだろう

254 :デフォルトの名無しさん:2010/04/26(月) 08:02:24
暇で必死なバカが一人いるな、という感じに見える

255 :デフォルトの名無しさん:2010/04/26(月) 09:23:08
>>245
つまりはそういうことだね。


256 :デフォルトの名無しさん:2010/04/26(月) 09:55:09
仮にファイル名だけ文字コード変換したとしても、
Makefileみたいにファイル名を直に書いているファイルがあるとうまくいかなくなるよな

ファイル名だけじゃなくてファイルの内容まで含めた包括的な文字コード変換の仕組みが必要なんだけど
どのエンコーディングからどのエンコーディングに変換すればいいかがいまいち自明じゃない
変換失敗のときにどう動作すればいいのかとか、
文字コード変換しなくていいファイルはどう指定すればいいのかとか、
問題は山積している

だからそういう問題を忘れて、POSIX APIを仮定して(ファイル名=バイナリ文字列)プログラムを書くというのは
それなりにわかりやすい態度だと思うのよね

257 :デフォルトの名無しさん:2010/04/26(月) 09:56:08
GNU周りってモノはそんな悪くないんだけど、コミュニティが最悪にガキ臭いよね。
Gitが文字コード問題に取り組まないのも、大嫌いなWindowsに関わる事なんざ知ったこっちゃ無いと言う小学生レベルの理由以外は何も無いし。

258 :デフォルトの名無しさん:2010/04/26(月) 09:59:09
>>256
ファイルの中身のエンコーディングについてはバージョン管理システムは関係ないだろう。
勝手にごっちゃにして実際に発生している問題を正当化する材料にするのはおかしくないか?

259 :デフォルトの名無しさん:2010/04/26(月) 10:01:12
>>256
OS含め全てがマトモに文字として扱っている限りはそんな下らん問題は発生しない
問題が発生するのは、どっかのタコプログラムが文字列(ファイル名等)をただのバイト列として扱うから

260 :デフォルトの名無しさん:2010/04/26(月) 10:14:51
>>259
> マトモに文字として扱っている

マトモな文字の扱いかたをしてるものって、EmacsとRubyぐらいしかないんじゃね?
OSなんか全滅だろ。

261 :デフォルトの名無しさん:2010/04/26(月) 10:25:51
うん、Unix派生OSは全滅だね

262 :デフォルトの名無しさん:2010/04/26(月) 10:29:22
つまりgitは無責任にOSに文字列の扱いを丸投げしているだけで
実際に文字化けを起こしているのはLinuxとかのタコOSなんだよ

263 :デフォルトの名無しさん:2010/04/26(月) 10:52:33
>>257 gitはGNUが作ってるわけじゃないけど。

264 :デフォルトの名無しさん:2010/04/26(月) 11:39:20
>>251
確かにLinusはSubversionをバカにしたけど、Windowsで日本語ファイル名がダメ
とかっていうのは、単純にWindows使わないから知らんがなーなだけ
だと思う。Windowsダッセーとかっていうのは昔から言ってるしね。別の話だよ。

265 :デフォルトの名無しさん:2010/04/26(月) 18:34:22
gitに興味持ってこのスレ覗いたwinユーザーは安易にgitを使わないで下さい。

winでは文字化けします。

勝手に導入すれば周りに迷惑を掛けるのがオチです。

導入したいならWindowsを捨ててください。

266 :デフォルトの名無しさん:2010/04/26(月) 20:12:28
日本語を捨てるのが先

または、全部ローマ字でkakebaZenbuKaiketsuDesu.

267 :デフォルトの名無しさん:2010/04/26(月) 20:58:06
同じマルチバイトの中国語や韓国語は問題ないの?

268 :デフォルトの名無しさん:2010/04/26(月) 21:26:16
田舎アプリユーザーはASCII以外興味ないんです
無理言わないであげてください

269 :デフォルトの名無しさん:2010/04/26(月) 22:23:45
>>267
ASCII Onlyでないやつはすべて問題あります
それでも日本がダメだと言い張るのがこのスレのクオリティー

270 :デフォルトの名無しさん:2010/04/26(月) 22:31:34
gitはlinuxどうしでもlocaleが違うとだめだよね

271 :デフォルトの名無しさん:2010/04/26(月) 22:32:19
Linuxが糞なだけでgitは悪くないっしょ

272 :デフォルトの名無しさん:2010/04/26(月) 22:48:09
Linuxの世界ではファイル名は文字列じゃなくてバイト列なんだよ
('\0' と '/' 以外の任意のバイトが使える)

これはバグとかそういう問題じゃなくてただの文化の衝突だからどうにもならん

273 :デフォルトの名無しさん:2010/04/26(月) 23:10:42
そんなん何十年も昔の妥協点を未だに引きずってるだけの話でしょ
文化の衝突じゃなく、単にコミュニティがascii以外に興味が無いだけとしか思えない

274 :デフォルトの名無しさん:2010/04/26(月) 23:23:55
http://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-007ACA9B
Windowsの方も、アプリケーションにSJISでファイル名を渡してくるような状況を変えられないとねぇ…

275 :デフォルトの名無しさん:2010/04/26(月) 23:25:40
あと、そもそもLinuxはOSがロケールにアクセスしないから
システムコールレベルで文字コード変換を云々するのはそもそも不可能だな

276 :デフォルトの名無しさん:2010/04/26(月) 23:32:16
>>274
知らんなら黙れ
SJIS自動変換は当たり前にOFFにできる

277 :デフォルトの名無しさん:2010/04/26(月) 23:43:22
>>276
offってどうやるの?
別関数使うならわかるけど

278 :デフォルトの名無しさん:2010/04/26(月) 23:46:46
馬鹿には見えないマクロ郡を使って

279 :デフォルトの名無しさん:2010/04/26(月) 23:59:30
.netのSystem.Diagnostics.Processで引数としてファイル名をUTF-8で渡す方法は?

280 :デフォルトの名無しさん:2010/04/27(火) 00:04:04
突然関係ない都合の良い話を始めるのはgit病の症状なの?

281 :デフォルトの名無しさん:2010/04/27(火) 00:07:10
Git脳の恐怖

282 :デフォルトの名無しさん:2010/04/27(火) 00:14:44
>>280
ファイル名関連はBzr病だと思う

283 :デフォルトの名無しさん:2010/04/27(火) 00:49:18
OSがファイル名をUnicodeとして管理している場合と
OSがファイル名をただのバイト列としか思ってない場合とじゃリスクは比べるべくも無い

284 :デフォルトの名無しさん:2010/04/27(火) 01:51:17
ここで修正パッチも出さずに、gitがWindowsでうんこといっても
暗にhgもクソ、Bzrマンセーしているようにしか見えないし

285 :デフォルトの名無しさん:2010/04/27(火) 01:55:35
せっかく賑わってきたので現実的な解決方法を話しあいたい。

ぶっちゃけアドホックでもいいので
「Windowsで(UTF-8なcygwin環境以外でも)日本語ファイル名が
他のプラットフォームと相互運用してもSubversion並に問題ない」というような
(↑要点あってるよね間違ってたら言って)
現実的な解決方法って何かないもんなんでしょうか?
Windowsユーザー的にはツールはTortoiseGitとmsysgit辺りでなんとかなればいいんだと思う。

286 :デフォルトの名無しさん:2010/04/27(火) 03:25:13
身も蓋もないことを言うようだが、TortoiseとかでGitやっても、Subversionと同じ使い方しか
しないような気がする。そんなことない? 失礼しました。

287 :デフォルトの名無しさん:2010/04/27(火) 08:12:44
>>286
同じじゃだめなの?
コミットがローカルにされて、pushとpullを覚えるくらいのイメージなんだが。
ブランチだなんだと面倒なことは慣れてから理解。

いきがってstashとか使ってたら大昔のやつをpopしてしまって
コンフリクトの嵐。戻し方がわからず泣きそうになった。resetとか怖い

288 :デフォルトの名無しさん:2010/04/27(火) 08:35:27
gitはrebase -iで履歴を組み換えるのが楽しいぞ。


289 :デフォルトの名無しさん:2010/04/27(火) 12:17:17
>>285
>>110

Mac問題はシラネ

290 :デフォルトの名無しさん:2010/04/27(火) 13:19:59
>>287
いや、ダメっていうか、svnと同じ使い方しかしないのなら、移行にかかる学習コストや
既出の障壁なんかを考えると、無理に導入する必要あるのかな、と。

291 :デフォルトの名無しさん:2010/04/27(火) 15:40:38
なんども言われてる事だと思うけど>>285みたいなのはSubversion使うべき
無理にgit導入すれば周りから迷惑な奴と思われてしまうよ
さらにgitの文字コード問題を知ってる奴から見たら馬鹿な奴と思われるだけ

292 :デフォルトの名無しさん:2010/04/27(火) 15:56:53
なぜ無意味に上に立ちたがるのか

293 :デフォルトの名無しさん:2010/04/27(火) 16:32:19
subversionなら日本語ファイル名の相互運用が問題ないっていう妄想はどこからくるわけ?

294 :デフォルトの名無しさん:2010/04/27(火) 23:29:45
>>293
ja_JP.UTF-8 のDebianで「十表.txt」を作成、svnでコミット。
これをWindowsのTortoiseSVNでチェックアウト。問題なし。もちろん逆も。

これくらいのことなら、もちろんGitでもできるんだよね。
これくらいのことが普通にできればそれでいいんだよ。

295 :デフォルトの名無しさん:2010/04/27(火) 23:42:52
>>290
・ 全ディレクトリに.svnが作られ、ディレクトリのコピーが気楽にできない。
ネストしたディレクトリのコピーとか、結構面倒。そのままコミットするとsvnが錯乱する
・ 全ての編集が毎度中央レポジトリにされるので、一時保存的なコミットができない。
  なんか恥ずかしいし、あとから見たらゴミでしかない。
・ やっぱり、ネットが切れててもコミットしたい状況はある。

別にgitじゃなきゃいけないわけじゃないけど、この辺はなんとかしたい。

296 :デフォルトの名無しさん:2010/04/27(火) 23:46:05
終了してしまったけど、svkはローカルリポジトリの履歴を
上流にpushするときに改変できたりしないの?


297 :デフォルトの名無しさん:2010/04/28(水) 01:04:28
>>296
svkはできるよ。svnリポジトリ間のマージにも重宝する。
ただ、けっこうかなり重たいんだよな。。。
でも
* .svnは無い
* ローカルコミット可能
* リモートにpushする時にまとめたり出来る
ってのは>>295の要望には合ってそうだね。

298 :デフォルトの名無しさん:2010/04/28(水) 01:07:07
svnの延長として分散型使いたいならBzrは悪くない

299 :デフォルトの名無しさん:2010/04/28(水) 01:27:36
逆に、Bazaarは何がイケてないんだろ
使い方が難しいのかな

300 :デフォルトの名無しさん:2010/04/28(水) 02:17:43
まあ、後発だからな > bzr

301 :デフォルトの名無しさん:2010/04/28(水) 06:08:21
社内のバージョン管理をgitで統一しようと思う
日本語ファイル名禁止のメールを全員に送らにゃならんが

302 :デフォルトの名無しさん:2010/04/28(水) 09:10:53

             |
〜〜〜〜〜〜〜〜|〜〜〜〜〜〜〜〜〜〜
   >( c´_ゝ`)  |
            |
>( c´_ゝ`)     J
     >( c´_ゝ`)



             |
〜〜〜〜〜〜〜〜|〜〜〜〜〜〜〜〜〜〜
             |     >( c´,_ゝ`)
             |
             J   >( c´,_ゝ`)
                    >( c´,_ゝ`)


303 :デフォルトの名無しさん:2010/04/28(水) 10:20:22
>>299
何でもできるような余地(集中型・分散型どっちもおkとか)を残しすぎてて、
内部の動作を理解しないと使いにくそうに見えるところ。
リポジトリとブランチは別物とか言われても、「なにそれこわい」にしかならんと思う。

304 :デフォルトの名無しさん:2010/04/28(水) 23:00:33
>>299
むしろ逆。普段からgithubとか使ってるとなんでgitじゃねーんだよ!って感じになる

まあ、仕事でWindowsだとBazaar、趣味やOSS開発だとgitとつかいわけてもいいんだが

305 :デフォルトの名無しさん:2010/04/29(木) 00:15:35
>>303
> 内部の動作を理解しないと使いにくそうに見える
これはまさにgitにも言えることではないかと思うんだが、gitはあれでシンプルなのか?
rebaseとか言われた時点で、あ、これ無理とか引いてしまう

306 :デフォルトの名無しさん:2010/04/29(木) 00:34:08
構造的に最もシンプルなのはgitだろう
だからといって使う人が理解しやすいかということは別問題

307 :デフォルトの名無しさん:2010/04/29(木) 00:38:24
gitはresetでコミットが消えるとか言われた
コミットが消えるバージョン管理とか、なにそれこわい
どこかには残ってるんだよねそう言ってよママン

308 :デフォルトの名無しさん:2010/04/29(木) 01:42:38
正直gitには、
ttp://d.hatena.ne.jp/idesaku/20091106/1257507849
こういう情報がもっと一般的に、大量に、言い換えれば懇切丁寧に、公式に、これくらい柔らかく必要だ

309 :デフォルトの名無しさん:2010/04/29(木) 02:34:12
>>285
msysgitはどうにもならないと思う。
TortoiseGitのバックエンドをcygwin版gitにする方が見込みがありそう。

310 :デフォルトの名無しさん:2010/04/30(金) 23:17:18
gitは趣味に留めて業務で使わないでくれよおまいら

311 :デフォルトの名無しさん:2010/05/01(土) 04:20:22
Gitはおもちゃだし

312 :デフォルトの名無しさん:2010/05/01(土) 10:48:38
そのおもちゃをソースコード管理に使っているLinuxはしょせんおもちゃプロジェクトであり
シェアなど1%前後で十分ってことだ
ttp://marketshare.hitslink.com/os-market-share.aspx?qprid=9

313 :デフォルトの名無しさん:2010/05/01(土) 20:46:02
↑Winユーザーの嫉妬はみっともないな

314 :デフォルトの名無しさん:2010/05/01(土) 21:23:18
↑おもちゃユーザーの嫉妬はみっともないな

315 :デフォルトの名無しさん:2010/05/02(日) 10:25:41
mercurial-1.5.2.tar.gz

316 :デフォルトの名無しさん:2010/05/02(日) 12:14:04
なぜ hg のスレに書かずに、ここに。

317 :デフォルトの名無しさん:2010/05/02(日) 15:00:34
バカなWinユーザーがいつまでもgitに嫉妬してるからです
早く別のを使えばいいと思います

318 :デフォルトの名無しさん:2010/05/02(日) 15:20:47
↑gitがこんな考えしてるから無駄に叩かれるんだよ

319 :デフォルトの名無しさん:2010/05/02(日) 15:55:37
前のほう読むと、Windowsに対応してないとか意味わかんない! って突っかかってるように見えるが

320 :デフォルトの名無しさん:2010/05/02(日) 16:00:31
gitにshit
yeah

321 :デフォルトの名無しさん:2010/05/02(日) 17:09:04
>>319

322 :デフォルトの名無しさん:2010/05/02(日) 18:09:12
>>319
そんなのLinuxをおもちゃとか言ってるバカの粘着だけだよ
お子様にはsvnを使ってもらいたいねぇ

323 :デフォルトの名無しさん:2010/05/02(日) 20:18:32
ほら、無駄にsvnを見下してる
文字コード問題とか言う初歩的なバグを直せていないのにコレだよw

324 :デフォルトの名無しさん:2010/05/02(日) 20:23:10
良いと思うならメリットを論じれば良いのに

325 :デフォルトの名無しさん:2010/05/02(日) 20:55:02
>>323
バグじゃなく、実装されてないだけ
その違いがわからないならム板でレスしないでね

326 :デフォルトの名無しさん:2010/05/02(日) 21:41:47
仕様って素敵やん

327 :デフォルトの名無しさん:2010/05/02(日) 23:55:12
>>325は確実にMSの「仕様です」回答を散々馬鹿にした奴らの一人

328 :デフォルトの名無しさん:2010/05/03(月) 00:49:44
仕様よ仕様。でもちょっとだけ仕様じゃないの。


329 :デフォルトの名無しさん:2010/05/03(月) 01:47:39
仕様バグって奴か。
一番深刻だな。

330 :デフォルトの名無しさん:2010/05/03(月) 01:57:40
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ!」って振りをする為、
仕様って事にしたいんですね、わかりますん。

331 :デフォルトの名無しさん:2010/05/03(月) 02:16:06
つーか想定外の用途なので欲しい人頑張って。



332 :デフォルトの名無しさん:2010/05/03(月) 02:20:39
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ!」って振りをする為、
想定外の用途って事にしたいんですね、わかりますん。

333 :デフォルトの名無しさん:2010/05/03(月) 02:38:09
問: gitは何のために作られましたか?


334 :デフォルトの名無しさん:2010/05/03(月) 02:43:15
Linuxで使えればOKと思われている以上……ね。
ttp://www.garbagecollect.jp/~usa/d/200904b.html#id20090417_P1
# 1年前のエントリだが。


335 :デフォルトの名無しさん:2010/05/03(月) 02:59:22
>>332
特定のOSの開発用に作ったバージョン管理システムが、とあるプラットフォームで
動かないからクソだって罵るのは別に自由だし、他のを使えば済むことだし、
あなたの意見はよく分かったから勝手にして欲しいんだけど、いつもまでも同じ主張を
延々とやられるとウザったいからもういいよ。

336 :デフォルトの名無しさん:2010/05/03(月) 03:00:45
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ!」って振りをする為、
特定のOSの開発用に作ったって事にしたいんですね、わかりますん。

337 :デフォルトの名無しさん:2010/05/03(月) 03:07:29
こいつもうただの荒らしだな。
Gitが何を目的にして作られたのか知らないのか?

338 :デフォルトの名無しさん:2010/05/03(月) 03:25:26
要するに不用意にWindows版作ったgit開発者が悪い

339 :デフォルトの名無しさん:2010/05/03(月) 03:35:33
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ!」って振りをする為、
Gitが何を目的にして作られたのか知らないのか?って事にしたいんですね、わかりますん。

340 :デフォルトの名無しさん:2010/05/03(月) 03:55:40
結論は>>338

341 :デフォルトの名無しさん:2010/05/03(月) 04:16:02
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ!」って振りをする為、
ベースではなくWindows版だけが悪かったって事にしたいんですね、わかりますん。

342 :デフォルトの名無しさん:2010/05/03(月) 04:38:33
>>331
こういうこと言ってる奴ほどMSのこういう態度を批判するんだよなwww

343 :デフォルトの名無しさん:2010/05/03(月) 06:16:26
>>342
MSの場合ソースコード非公開だから、頑張りようがないと思うが

344 :デフォルトの名無しさん:2010/05/03(月) 06:25:26
ん?頑張って他に移ってねって話では?
散々svn使えって言ってきてるじゃん

345 :デフォルトの名無しさん:2010/05/03(月) 06:32:11
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ!」って振りをする為、
svnはクソだからgitを造ったのに結局使うなって事にしたいんですね、わかりますん。

346 :デフォルトの名無しさん:2010/05/03(月) 14:56:31
言い出しっぺの法則というものがありましてね

347 :デフォルトの名無しさん:2010/05/03(月) 15:42:31
そうだね、Windows版作ろうとか言い出した奴は最後まで責任持たないとね

348 :デフォルトの名無しさん:2010/05/03(月) 15:59:17
>>345
gitに嫉妬してここで文句言えば誰かがgitをWin用に対応してくれるとでも
思ってるだろお前?
幼稚なコピペばかり繰り返して頭悪いんじゃない?
造ってる人間達に能力がない為と言うなら自分で対応しろよ


349 :デフォルトの名無しさん:2010/05/03(月) 16:41:53
嫉妬とかそういうくだらん発想で会話するから、馬鹿にされるんだよ

350 :デフォルトの名無しさん:2010/05/03(月) 17:26:45
ここで暴れているのってgitばっかりのような気がする。

351 :デフォルトの名無しさん:2010/05/03(月) 17:54:53
信者が必死なんだろ

352 :デフォルトの名無しさん:2010/05/03(月) 18:29:17
誰がどう見てもアンチが必死

353 :デフォルトの名無しさん:2010/05/03(月) 18:46:21
日本語表示できないのは事実なんだから適当に流せばいいのに
いちいち言い返さないと気がすまないもん同士でエスカレートしてるだけ

354 :デフォルトの名無しさん:2010/05/03(月) 19:05:15
誰か他の話題たのむ。

CVSの話でもするか。

355 :デフォルトの名無しさん:2010/05/03(月) 19:37:18
ミンナダイスキ
IBM Clear Case

356 :デフォルトの名無しさん:2010/05/03(月) 19:51:51
で、ちょっと分散型のを使ってみようかとなったら、
・WinでもLinuxでも
・日本語ファイル名なんざ金輪際使わねぇなんてポリシーは無い
って場合には、gitは駄目で将来的にも直りそうに無いということは
分かりました。

とすると、マーキュリアルとかいうのとバザールでござ〜るの
どっちが良いんでしょうか。

357 :デフォルトの名無しさん:2010/05/03(月) 22:57:01
>>356
その二択なら、迷わずbzrを取った方がいいような気がする。
両方コミュニティの雰囲気とかよく知らないけど。
hgのgitに対する優位って何かあるの?

358 :デフォルトの名無しさん:2010/05/03(月) 23:17:08
hgも日本語対応のパッチはrejectされたんじゃなかったっけ?
まともに期待できるのはbzrしかなさそう

359 :デフォルトの名無しさん:2010/05/04(火) 00:05:21
>>357
hgはgitと比べたら、基本的にpythonだけで動くところと、コマンドラインで
使いやすいのがメリットかな

360 :デフォルトの名無しさん:2010/05/04(火) 00:24:36
そのマニアックな利点を利点と感じられる人間は、ぶっちゃけ何でも使えるだろ
gitと同じ日本語問題を抱えてるなら、乗り換え先として魅力はかなり少ないような

ちょっと本腰いれてbzr使ってみるかな
bzrは、以前触ったときにはTortoiseよりもむしろBazaar Explorerがいい感じだと思った
あとはCUI出力(log とか status)に色が付けられたら、たぶん文句なく使えそう

361 :デフォルトの名無しさん:2010/05/04(火) 02:06:41
「日本語対応」とか言ってるから、git儲がいつまでも付け上がるんだぜ。
「国際化対応」と言えば、もちろん「できない・やらない方が悪い」。
つまり、git儲は視野が狭い独善的な国際的悪者なのだ!

362 :デフォルトの名無しさん:2010/05/04(火) 03:45:38
またバカが来たよ

363 :デフォルトの名無しさん:2010/05/04(火) 04:13:32
よっぽど恨みに思うようなことがあったんだろうな

364 :デフォルトの名無しさん:2010/05/04(火) 05:06:01
国際的患者に見えたわ

365 :デフォルトの名無しさん:2010/05/05(水) 08:32:21
Git と Mercurial が Subversion より優れている点 - tcha.org
http://tcha.org/blog/2010/02/01/dvcs-over-svn/

366 :デフォルトの名無しさん:2010/05/05(水) 09:07:04
Subversionが(現状)GitやMercurialより優れている点

・ 変更の確認…アイコン見るだけ。diff・mergeは右クリックでWinMergeU
・ その他のほぼ全ての操作…右クリックでごにょごにょ

何を言っても、全てはこれに尽きるだろ。

あと、Gitは自動マージに頼りすぎで、衝突の解決をさせる強制力が弱い気がする。
なんでもかんでも add . でコミットできてるんじゃねーよ。これは使う人間次第だろうけど。

367 :デフォルトの名無しさん:2010/05/05(水) 10:15:29
>>366
それはTortoiseSVNの機能。Subversion自身にそんな機能は無い。

368 :デフォルトの名無しさん:2010/05/05(水) 10:27:56
早くGitにもすてきGUIを作ってくれよ

369 :デフォルトの名無しさん:2010/05/05(水) 10:43:31
>>368
あっても無駄だろ。
ファイル名を文字として認識して無いという国際化対応での駄目っぷりが直らない限り。

370 :デフォルトの名無しさん:2010/05/05(水) 11:08:41
gitみたいな複雑な利用をするものほど、GUIの恩恵は大きいと思うんだ

git reset は HEADの位置を動かす? おk、今どこにいるの?
git stash で修正をスタックに棚上げ出来る? おk、今どれだけ積んでいて、どれが何時の分?
branch が基本で今時のSCMには必須? おk、どこからどうやって分かれて今どうなってるの?

みたいなのが、結局記憶ベースかコマンドからのテキスト読解もしはハッシュコピペベースって、
お世辞にも使いやすいとは言えない

371 :デフォルトの名無しさん:2010/05/05(水) 11:23:40
>>368
つTortoiseGit

372 :デフォルトの名無しさん:2010/05/05(水) 11:51:24
>>366
> 366 名前:デフォルトの名無しさん [sage]: 2010/05/05(水) 09:07:04
> Subversionが(現状)GitやMercurialより優れている点
>
> ・ 変更の確認…アイコン見るだけ。diff・mergeは右クリックでWinMergeU
> ・ その他のほぼ全ての操作…右クリックでごにょごにょ
>
> 何を言っても、全てはこれに尽きるだろ。
>
> あと、Gitは自動マージに頼りすぎで、衝突の解決をさせる強制力が弱い気がする。
> なんでもかんでも add . でコミットできてるんじゃねーよ。これは使う人間次第だろうけど。

TortoiseHg ならほとんど全部 GUI で出来る。
コミッタに日本人2人いるから、がんがん要望を日本語であげることもできる。
メニューなどの日本語化も終わっているし。


373 :デフォルトの名無しさん:2010/05/05(水) 13:01:05
の割にはスレにぎわってないよねえ。
不満がないのかあきらめてんのか。

俺は……まあ両方かな。bzr と併用しつつ様子見。

374 :デフォルトの名無しさん:2010/05/05(水) 14:51:13
自分はシェルでのCUI操作とgitk(gitリポジトリ履歴ビューア)の併用で慣れてしまったし別に。
他のバージョン管理システムも、そう悪くないんじゃないかとは思うけどね。

日本語ファイル名使えないとヤダヤダ、全部GUIじゃないとヤダヤダって人達とは
今のところは一緒に作業する事は無いし、往々にして困ったちゃんが多い印象があるからなぁ…

使い易いGUIやインストーラなどを整備するのは別に拒まないけど、
個人的には、クレクレ&FUD猿状態の連中にまで仏心を振りまく気概は無いし。
付き合ってストレスばかり感じる相手に、無償で奉仕する義理は無い。

あと、svn/git/hg/bzrに限らずバージョン管理システムのクライアントは
Tortoiseのようなエクスプローラ統合型だけでは無く、
Eclipse/NetBeansなどの統合型開発環境への組み込み型プラグインという形態もあるのだから、
用途によってはGUI等の実現はそちらの方が便利、というケースもあるんじゃ?

375 :デフォルトの名無しさん:2010/05/05(水) 16:48:32
そんなに内容の無い長文書いてなにがしたいの?

376 :デフォルトの名無しさん:2010/05/05(水) 16:52:18
批判されないように妥当な事ばかり書いたら何も内容が無かったと言う

377 :デフォルトの名無しさん:2010/05/05(水) 18:22:07
>>370
俺は逆にマウスでポインタ合わせしまくらないといけないGUIのほうが疲れるな。
コード書きもGUI使わないし、マウスでコミットとか何か間違えそうで怖い。
ただマージが複雑になってくるとgitkみたいなのが無いと理解するのは難しいね。
>>370みたいな人が居るってことは、そのうち使いやすいGUIも誰か作るんじゃない?

378 :デフォルトの名無しさん:2010/05/05(水) 20:55:45
ちょっと前、Java の Mercurial 環境の試しで、
NetBeans は NetBeans が Mercurial で開発されているので、何もしないで使えた。
Eclipse も結構いい線いってた気がした。
結局、Mercurial はコマンドラインで、Java は maven が一番快適だったが。


379 :デフォルトの名無しさん:2010/05/05(水) 21:11:58
自分は普段はコマンドラインで使ってるけど、
人のコードを調べたり、人のコードをレビューする時の道具として使うときは
GUIとWebUIの方が楽ちんだな。



380 :デフォルトの名無しさん:2010/05/05(水) 21:32:11
>>372
Junioって日本人として全く役に立ってないんだねぇ

381 :デフォルトの名無しさん:2010/05/05(水) 21:55:35
>>372
TortoiseHg前に使っててすごい便利だったけど(部分的にはTortoiseSVNより便利だったところ合った気が)、
Mercurialがマルチバイトファイル名の問題が解決されないので今は様子見中だわ・・・

コマンドラインで使うならUTF-8のcygwin hg使えば解決できるけど、
それならgit使うw

>>374 >>378
たまたまSubversionのプロジェクトでNetBeans使ってたら、
SVNに対応されててプロジェクトのファイルビューアーがTotoiseSVNみたいにアイコン変わったり、
エディタで変更箇所示してくれたり便利だったな。

IDEの組み込みは便利なんだが、IDEを変えられないという欠点が…。
言語ごとに適してるIDEがあるから、下手すると言語ごとにバージョン管理システム変えるハメに(はならないかw

382 :デフォルトの名無しさん:2010/05/05(水) 21:57:27
>>380
日本語メールはスパムとして弾いてるほどの人だし

383 :デフォルトの名無しさん:2010/05/05(水) 22:05:02
>>380
JunioってGITのPLだろ?

384 :デフォルトの名無しさん:2010/05/05(水) 23:14:39
マルチバイト圏の人間のクセにシングルバイトしか考えないこの有様
一体どれだけ無能なのやら

385 :デフォルトの名無しさん:2010/05/05(水) 23:33:49
>>382
mjd?

386 :デフォルトの名無しさん:2010/05/06(木) 01:18:27
>>382 >>384
そういう人じゃなきゃ、gitやhgは馴染まないってことだろ
無理して日本語Windows環境を捨てて開発しなきゃいけないとかおかしい

ぶっちゃけCygwinなんて興味ない人に使わせるの無理ありすぎだ
精々、Macオンリーまでが許容範囲じゃなかろうか

387 :デフォルトの名無しさん:2010/05/06(木) 09:59:28
いいえ

388 :デフォルトの名無しさん:2010/05/06(木) 13:35:04
自助努力という言葉が辞書にないのがドザ、ってことだけはよくわかった。

389 :デフォルトの名無しさん:2010/05/06(木) 13:50:44
Windowsは関係ない
前世紀から使っているようなeucJPのNetBSD機が混在しただけでも破綻する

390 :デフォルトの名無しさん:2010/05/06(木) 15:58:59
Mac OS Xのように、UTF-8 と UTF-8-MAC という微妙な差異も意外と苦しそう。
(主に濁点・半濁点を用いた平/片仮名文字)

391 :デフォルトの名無しさん:2010/05/06(木) 17:44:31
>>390
gitやhgをクイックハックでなおすとすると、WindowsよりMac対応のほうが面
倒くさそうだよね

392 :デフォルトの名無しさん:2010/05/06(木) 18:53:13
MacOSX はそれが本当に面倒でなぁ。


393 :デフォルトの名無しさん:2010/05/06(木) 23:09:48
エンドユーザに自助努力を要求するようになったら開発者としちゃ下の下。
余計な苦労は無いに越した事はない。

394 :デフォルトの名無しさん:2010/05/06(木) 23:20:04
例えば誰?

395 :デフォルトの名無しさん:2010/05/06(木) 23:33:33
NFCとNFDの違いはUnicodeの仕様だから我慢するとして、
他にもMacは文字マッピングが違うところがあるらしいけど、
具体的にドレ?


396 :デフォルトの名無しさん:2010/05/06(木) 23:44:55
その辺、普通にスレ違いにも程がある話題ではあるんだ

日本人だからまだそれなりにみんな関心あるだろうけど、
git開発者連中にしたら、どうでもよすぎるんだろうなあ
結局はそういうことだろ

何が何でもbzrを盛り上げて、svnかbzrの二択にできないもんかね

397 :デフォルトの名無しさん:2010/05/06(木) 23:48:39
>>389
ああっ!ってか確かにそうだよな。
Linuxなんかはいつの間にか(というと失礼と無知さらしだが)UTF-8当たり前になってたから最近はいいんだが、
以前のEUC_JPからの環境はWindowsと同じで切り捨てってことか。

>>390
最近、たまにwebでまれによく見る濁点と半濁点がかなと別に表示されている、みっともない文字のことかな?
ブラウザでテキストで選択すると一緒に選択されるもしかしてあれか?

398 :デフォルトの名無しさん:2010/05/06(木) 23:52:49
>>397
Linuxの場合は、locale切り替えでなんとか対応出来るんじゃね?既存ファイルは別として
Windowsでもそれができれば別に問題ないとも言えそう。まあできないんだがな。

399 :デフォルトの名無しさん:2010/05/06(木) 23:56:14
>>390
濁点とかアクセント付き文字はUnicode自身が合成済みのと分離状態
の両方の文字を持っていて、利用システムで好きな方式を採用してい
いんだけど、両方区別なく扱えるようにしてよね、ということになっ
ている。



400 :デフォルトの名無しさん:2010/05/06(木) 23:59:46
>>396
日本語対応の観点から、現実的にはすでに svn と bzr の二択
しかないと思うが、git と mercurial はググったら日本語の
解説ページがいろいろ引っかかるのに対し、bazaar でググると
もともと日本語のページは少ないうえに、物を売るバザーの
ページもたくさん引っかかって情報収集がしにくいので、
まず情報収集しやすい git か mercurial に手を出してしまう、
という罠があると思う。

401 :デフォルトの名無しさん:2010/05/06(木) 23:59:58
>>399
つまり、RDBMSなんかでは両方ヒットするのが正しい実装、ってことでしょ?
エディタの検索・置換なんかでもしかり。
で、gitやhgでは?…って、聞くだけ野暮なんだろうね
subversionやbazaarができてるかどうかは別にして、"ポリシー"的に

402 :デフォルトの名無しさん:2010/05/07(金) 00:26:33
まあそろそろ、声を少しだけ大きくして言ってもいいと思う
ファイル名やましてやコミットログは、バイト列じゃないんだぜって
まずLattin-1を普通に使ってる奴をつるし上げればいいと思う

403 :デフォルトの名無しさん:2010/05/07(金) 00:30:24
Latin-1な
それってドザだろ

404 :デフォルトの名無しさん:2010/05/07(金) 00:36:14
忠告じゃないけど、”ドザ”って書くと「頭悪いMac信者」というアピールしているように見えるからやめた方がいいよ。
突然に中国とか韓国ネタ書くやつと大差がない。
不要に荒れる要素出す必要ないだろ

405 :デフォルトの名無しさん:2010/05/07(金) 00:37:19
おおっと、別に >>403 が「頭悪いMac信者」だと言っているわけじゃないからな、
誤解を生みやすい表現失礼

406 :デフォルトの名無しさん:2010/05/07(金) 00:37:49
文字=バイト列な田舎モンがドザドザ言ってるのはなんか滑稽

407 :デフォルトの名無しさん:2010/05/07(金) 00:40:41
シェア1%でこれだけ声がデカイ奴らなんだから、相当アレな奴等じゃないと勤まらんよね

408 :デフォルトの名無しさん:2010/05/07(金) 00:54:38
いいから黙ってアメリカ語使えおまいら

409 :デフォルトの名無しさん:2010/05/07(金) 00:57:58
fuck you

410 :デフォルトの名無しさん:2010/05/07(金) 01:18:20
fack you位言えよ

411 :デフォルトの名無しさん:2010/05/07(金) 01:30:39
b*******k

412 :デフォルトの名無しさん:2010/05/07(金) 01:33:47
gitやmercurialがUTF-8で問題ないってのも、単純に「ただそこにあったUTF-8」なら
あんまり問題ないみたいね、ってだけで、Unicodeがどうたらってことには全く無頓着
ってことでいいのかな

もちろんバージョン管理システムの開発って観点では、んなもん関心の対象じゃない
ってのはわからんでもないけど、使い勝手や発展性という点では正直、疑問だと思う

413 :デフォルトの名無しさん:2010/05/07(金) 01:59:07
満足に「文字」として検索できない時点で、相当のタコだと思うよ
UTF-8が非常に優れた物だったから辛うじて保ってるだけ

大喧嘩の末別れた上に、今でも事ある毎に叩いてる所の技術におんぶに抱っこで恥ずかしくないのかな、彼らは

414 :デフォルトの名無しさん:2010/05/07(金) 02:05:47
>>413
いや、そのためにUTF-8は生まれたんじゃないか。

今の時代、UTF-8専用でもかまわないと思うが、WindowsでANSI APIを使うのは
避けてほしいところだな。


415 :デフォルトの名無しさん:2010/05/07(金) 02:12:09
いいから黙ってアメリカ語使ってろおまいら

416 :デフォルトの名無しさん:2010/05/07(金) 02:15:14
hey boss, bull shit!

417 :デフォルトの名無しさん:2010/05/07(金) 02:24:07
Get out of here!!

418 :デフォルトの名無しさん:2010/05/07(金) 02:30:28
ゲラウトヒア!!

419 :デフォルトの名無しさん:2010/05/07(金) 02:34:30
Yes, you must'nt say "ゲラウトヒア!!", OK?

420 :デフォルトの名無しさん:2010/05/07(金) 04:59:14
>>413
一体どのUTF? win linux ms どのUTFも互換性ない上に、リビジョンがあるんだけど。

421 :デフォルトの名無しさん:2010/05/07(金) 07:42:00
>>420
バカ現る

422 :デフォルトの名無しさん:2010/05/07(金) 09:10:37
2008年の頃から、同じような話してんだな。

http://www.unkar.org/read/pc12.2ch.net/tech/1218083381
18 :デフォルトの名無しさん[sage]:2008/08/08(金) 23:36:58
bzrのいいところは、ファイル名がバイト列ではなくて文字列として扱われて、ちゃんとエンコーディング変換されること。
Windows上で ソ連.txt とか なんとか表.txt とかをaddして、LC_CTYPE=ja_JP.UTF-8なLinuxでチェックアウトすると、
きちんと文字化けせずにチェックアウトできてる。

Mercurialは「ファイル名はファイル内容と同じでバイナリ列」という扱いだけど、ファイル名なんてファイル
システムに書くときにエンコーディングされるし、CUIに表示されるときも、CUIで打ち込むときも
エンコーディングされた文字列を扱っているだけだから、このポリシーはダメダメ。

既にMLで議論されたが、ascii圏の人にはこの問題が理解できなかったらしい。
Python3.0に対応するときに理解できるかな。


423 :デフォルトの名無しさん:2010/05/07(金) 11:13:28
>>413
>大喧嘩の末別れた上に、今でも事ある毎に叩いてる所の技術におんぶに抱っこで恥ずかしくないのかな、彼らは
これはドコとどこの話?

424 :デフォルトの名無しさん:2010/05/07(金) 11:30:28
とりあえずASCIIを可変長のマルチバイトにして符号化方式も3種類くらい乱立させればいいんじゃね?
世界中が幸せになるよ

425 :デフォルトの名無しさん:2010/05/07(金) 11:34:21
いやASCIIはASCIIだし

426 :デフォルトの名無しさん:2010/05/08(土) 03:11:22
ASCII範囲を置き換えるくらい分かれよアスペル君

427 :デフォルトの名無しさん:2010/05/08(土) 03:32:55
msysgitでもUTF-8対応の動きあったんですね。
リリースバージョンには反映されてないみたいですが
TotoiseSVNのcygwin gitの対応はやる気ないみたいだし、msysgitで対応できればTotoiseSVNもなんとかなりそうなんもんですが

Public Git Hosting - git/mingw/4msysgit.git/commit
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commit;h=45867beb1b85a258482431cff2d8268fea4bc7ca

428 :デフォルトの名無しさん:2010/05/08(土) 09:24:46
TortoiseSVNって? TotoiseGitの間違いだよね?

というツッコミはさておき、msysgitマターでしょう常考
ていうかmsysgitインスコ不要にしてほしいと思う俺だ。

429 :デフォルトの名無しさん:2010/05/08(土) 10:15:06
他のバージョン管理ソフトみたいにlibgitみたいなのがあって、
それさえ読んでればgitの機能使えるとかだとできるんだろうねえ

430 :デフォルトの名無しさん:2010/05/08(土) 10:35:26
TotoiseGit はとにかく不安定。
ソース見たら、Windows オンリーぽかった。
TotoiseHg, TotoiseBzr みたいに、PyGtk, PyQt だったら何とかなりそうな気もするんだが。


431 :デフォルトの名無しさん:2010/05/08(土) 10:48:35
GUIが必要なのってWindowsユーザーくらいだろうから(自嘲)
ネイティブでいいと思う

432 :デフォルトの名無しさん:2010/05/08(土) 10:49:25
gitならTortoiseGITよりgit extentionsかな

433 :デフォルトの名無しさん:2010/05/08(土) 13:12:02
JGit - Java GIT ってのがあるみたいですね。
http://www.jgit.org/


434 :デフォルトの名無しさん:2010/05/08(土) 13:18:37
いらねぇ

435 :デフォルトの名無しさん:2010/05/08(土) 13:42:26
Javaって聞くだけで拒否反応が起きる俺はV2C使い

436 :デフォルトの名無しさん:2010/05/09(日) 07:33:38
gitで間違えたユーザー名でコミットした場合はどうやってなおせばいいんでしょうか?

git config user.name "new user"
git config user.email new_user@name.example.com
git commit --amend -m "saido commit"

のようにしてgit log -1してみても、authorが書き変わってくれません(´・ω・`)

437 :436:2010/05/09(日) 07:53:33
git commit --amend -m "saido commit" --author="new user <new_user@name.example.com>"
で行けました。

以下のコマンドで見ていたところ、
git log -2 --pretty=full
>>436の時点では authorは変わらずcommitは変わっていました。
コミット時に--author指定でauthorも変わりました。

ありがとうございました!

438 :436:2010/05/09(日) 08:13:03
ちょっと気になったのですが、>>436 のAuthorが国家的な機密情報(のようなもの)だった場合、
例えば仕事のリポジトリに間違って、個人の名前を入れてしまった場合です。
--amendで修正した前のコミットしたデータは、リポジトリに残っているようなことはないもんでしょうか?
git pushしなければリポジトリにはデータは残らないと考えてよいのでしょうか?

この辺のドキュメントはどこを見ればよいのでしょう?

439 :デフォルトの名無しさん:2010/05/09(日) 08:22:46
国家機密レベルなら、むしろ間違えたコミットの前まで戻って
もう一度やり直す(ブランチを切り直して無かったことにする)のがいいのでは?

まあpushしなければ全てはローカルでの出来事なのは確か
push前に確信が持ちたかったら、ドキュメントはむしろソース嫁レベルじゃないかと

440 :デフォルトの名無しさん:2010/05/09(日) 08:27:22
>>438
git gc するまではリポジトリに残ってるよ。pushした先も同様。
ドキュメントはgit help gc とか?

441 :436:2010/05/09(日) 09:26:49
ありがとうございます。
git reflog

git log --author="old_name" -p

のように試してみたのですが、git gcしても残りますね・・・。
amendだと残ってしまうん?

442 :436:2010/05/09(日) 09:37:40
x git log --author="old_name" -p
o git log --author="old_name" -g

ああ、reflogは共有されないんですね。まあ、いいのか。

443 :デフォルトの名無しさん:2010/05/11(火) 01:26:11
ログメッセージに書くべき内容って、バージョン管理ツールのマニュアルに書いてないみたい
なんだけど、どっかに文書でまとめられてたりしない?

444 :デフォルトの名無しさん:2010/05/11(火) 03:17:56
>>443
あなたは自分が何をすべきかご存じないのですか?

445 :デフォルトの名無しさん:2010/05/11(火) 03:21:07
あるわけねーだろ

446 :デフォルトの名無しさん:2010/05/11(火) 03:45:12
つ ChangeLog

447 :デフォルトの名無しさん:2010/05/11(火) 07:57:27
>>443
コード中に書くコメントとほぼ同じに考えればいいよ。
書くべきは「何故」そういう変更をしたのか。
後は、「どういう」変更をしたのかも簡単に添えておけば、
いちいちdiffする手間がちょっと省ける。
(ここがちょっとコード中コメントとは違うかな)

448 :デフォルトの名無しさん:2010/05/11(火) 08:46:45
関数名を変更とか、変数を追加とか、は比較的書く意味が薄いな。


449 :デフォルトの名無しさん:2010/05/11(火) 11:05:30
>>448
なんでそうしたか書けばいいじゃん。
実態と合わない命名を修正したとか、ソース整理したとか。

450 :デフォルトの名無しさん:2010/05/11(火) 11:12:41
そういう機能や仕様が変わらない変更は
ほとんど「リファクタリング」の一言ですましちゃうな

451 :デフォルトの名無しさん:2010/05/11(火) 12:53:43
trivial change
trivial change
trivial change
・・・

452 :448:2010/05/11(火) 13:19:17
>>449 うん、理由を書くならいいんだよ。それを否定してはいない。

453 :デフォルトの名無しさん:2010/05/11(火) 13:22:14
最悪なのは「いろいろ修正」とかだな。ログメッセージ空のほうがまだいい。

454 :デフォルトの名無しさん:2010/05/11(火) 13:26:35
>>453
(´;ω;`)ウッ…
偉い人も
「明日の自分のためにもちゃんとログを残しておけ」
って言ってるけどなかなか実践できてないや…

455 :デフォルトの名無しさん:2010/05/11(火) 13:46:30
ここまで総合するに,ログに書くべき内容は,
変更箇所 + 変更内容 + 理由
といったところでしょうか。
些細な変更には,変更内容と理由を合わせて "refactoring" などの一言でOKと。

ちなみに,ログの形式はどうされてますか?

456 :デフォルトの名無しさん:2010/05/11(火) 13:47:49
変更したモジュール名だけを書くやつもおる。


457 :デフォルトの名無しさん:2010/05/11(火) 14:26:21
>>455
自分の考えを述べてみよ。何のためにログメッセージを残す?

458 :デフォルトの名無しさん:2010/05/11(火) 14:31:29
変更箇所と変更内容は差分を見れば自明なので、最悪の場合差分を見ればいいけど、
理由を書いてないと変更した本人以外わけがわからなくなることが多い。


459 :デフォルトの名無しさん:2010/05/11(火) 17:07:05
お前ら何言ってんだ
ログに残すのは「何々がしたかった」に決まってんだろ
他の情報は全て蛇足でありノイズ

460 :デフォルトの名無しさん:2010/05/11(火) 18:18:19
> 「何々がしたかった」
で、それは実現できたの?できなかったの?

461 :デフォルトの名無しさん:2010/05/11(火) 19:04:07
>>460
バカなの?
そんなもの後になって運が良ければ分かるだけの話
「したかった事を実装した」直後には「したかった事が実現できた」など断言できん

462 :デフォルトの名無しさん:2010/05/11(火) 19:46:39
オプションの追加や、メソッドの追加は歴然と事実としてあるんじゃないの?
それを、オプションを追加したかった、メソッドを追加したかったと記述するのには違和感がある。

多分、実装途中のログの表現について言ってるんだと思うけど、
「〜中」や、現在進行形で良いのでは?


463 :デフォルトの名無しさん:2010/05/11(火) 20:02:59
自分の場合、
一連のコミットで共通になる事柄をTracとかRedmineとかのチケットに書いておいて、
コミットログは「○○のために××した、#xx」(#xxはチケット番号)にしてる。

464 :デフォルトの名無しさん:2010/05/11(火) 20:06:29
遊ぶ金が欲しかった(過去形)

465 :462:2010/05/11(火) 20:09:11
レスを勘違いしてたかもしれん。

「〜したかった」とそのままログに書くのではなく、
「何々がしたかった」を指針にその内容をログに書けってことかな。
理解しきれてないけど。

466 :デフォルトの名無しさん:2010/05/11(火) 20:34:14
後からバグが発覚したときに後悔しないようなコミットログにしようぜ。orz

467 :デフォルトの名無しさん:2010/05/11(火) 20:40:04
この変更をコミットしたのは誰だぁ
svn/git/bzr/hg blame


468 :デフォルトの名無しさん:2010/05/11(火) 20:41:44
>>459 した事を書け!!
とレスして欲しかったんですね。わかります。

469 :デフォルトの名無しさん:2010/05/11(火) 20:48:53
>>462
バカすぎる
お前の手書きした「メソッドを追加した」と言う情報に一体何の価値があるの?
そんなもん最もログに書く意味の無い、ノイズの極みだよ

後に問題とされるは「そのコード変更でコミッタが一体何をしたかったか」だ
前任者がコミットログに「オプション〜を追加したメソッド〜を追加した」とかだけを羅列してたら、ぶん殴りに行きたくならんか?

これで理解できないなら、もうお前はパッチをコミットログにコピペしとけ
抜け漏れが無いことが保証されてるから幾分マシ

470 :デフォルトの名無しさん:2010/05/11(火) 20:51:44
>>468
何も分かってねぇ
「した事」なんざDiff見りゃ分かる
「その意図」を残すのが最も重要

471 :デフォルトの名無しさん:2010/05/11(火) 21:49:44
お手本plz

472 :462:2010/05/11(火) 21:55:07
>>469
これは失礼しました。

要するに、上でも既に述べられてるけど、理由を書けってことね。
あなたの言葉を焼き直すと、動機を書けになるのかな。

473 :デフォルトの名無しさん:2010/05/11(火) 21:59:20
いや、目的を書けだろ

474 :デフォルトの名無しさん:2010/05/11(火) 22:29:15
>>472
何でそんなズレてんだか
動機なんてオマケだろ

「手動で〜するのが面倒だった(動機)」ので「自動で〜する機能を実装した(したかった事=目的)」

コードを追う上で面倒だったと言う感想なんざ要らん
コードを変更した理由として動機を書くのはタコ
コードを変更した理由として目的を書くのが正しい

475 :デフォルトの名無しさん:2010/05/11(火) 22:39:01
ユーザーから仕様変更の依頼があったので
っていう動機は?

476 :デフォルトの名無しさん:2010/05/11(火) 23:13:26
オマケとして付いてる分にはかまわん
目的抜かして動機だけ書けば良いと思ってるなら>>472と手を取り合って死ね

477 :デフォルトの名無しさん:2010/05/12(水) 00:41:20
目的を書く事が重要なのは同意だが、なるべく修正箇所の要約もログに残ってると便利だがなぁ。
改造目的を読んでコードの修正内容が連想できる場合は良いけど、そうでない場合に逐一Diffを
追いかけて目的のリビジョン探すなんて時間の無駄じゃね?

478 :デフォルトの名無しさん:2010/05/12(水) 01:03:16
目的とか動機という単語は、かなりメタな言葉だ。
新規実装の時とバグ修正の時と仕様変更の時で、それぞれコミットログに求められるものが違うだろう。

479 :デフォルトの名無しさん:2010/05/12(水) 01:07:20
>>474
その状況で「手動で〜するのが面倒だった」をログに書かないなんて、ありえない。

480 :デフォルトの名無しさん:2010/05/12(水) 01:13:49
自動化による効率化の為、とでも書けば満足なんじゃね?
動機と目的はそんなに遠い言葉じゃないと思うので、要はwhyを書けってことかな
howやwhat、where、whoは勝手にわかるのでいらねってことかと

481 :デフォルトの名無しさん:2010/05/12(水) 01:17:06
>>480
when が抜けてるぞ。いらないけどな

WHY > WHAT >>> (必要なら) HOW でFA?

482 :デフォルトの名無しさん:2010/05/12(水) 01:33:43
>>481
なぜその位置にwhatがあるんだ
たとえば「変更する」を補うと
なぜ変更したか→コミットログしとけ
何を変更したか→diffがあるよ
どうやって変更したか→どうでもいい

483 :デフォルトの名無しさん:2010/05/12(水) 01:46:33
ちょっと大きな修正の場合、「何をどうして」こうなったって記述が
必要になるケースはあるだろう

484 :デフォルトの名無しさん:2010/05/12(水) 01:49:07
機能追加のコミットなんかは、まさにwhatがメインだな
原則さえ抑えておけば、ケースバイケースでいいじゃないか

485 :デフォルトの名無しさん:2010/05/12(水) 01:52:14
普通、コミットログは、1行目だけは特別扱いされてる。
だから、1行目は見出しとして書くべき。2行目以降は妥協しても良し。

486 :デフォルトの名無しさん:2010/05/12(水) 01:58:53
「それをなぜしたのか」 → why
「それは何をしたのか」 → what
「その修正はどういうロジックなのか」 → how

こんな所だろ?それぞれ必要なケースも容易に想像できそうだけど…
最初以外は、ソースのコメントに書くべきかもしれないとか、そういうことなのかな

487 :デフォルトの名無しさん:2010/05/12(水) 07:24:44
「What」はDiff見ろって効率悪過ぎだろ
リビジョンいくつあると思ってるんだよ。

488 :デフォルトの名無しさん:2010/05/12(水) 07:42:04
全部のWhat見て何がしたいの?
Diff見るのすら手間になるような数のコミットで、漏らさず変更箇所を書く労力は考えないの?
後で漏れてた事に気付いたらどうやって修正するの?

489 :デフォルトの名無しさん:2010/05/12(水) 07:50:49
もちろん後の祭です(キリッ

490 :デフォルトの名無しさん:2010/05/12(水) 08:01:28
というか、変更箇所の要約無いとダメとか言ってるお猿さん達はpatchをgrepする脳みそを備えてないの?

491 :デフォルトの名無しさん:2010/05/12(水) 08:02:34
例えば、こんな感じ?
Why ZZ社 特許XXXXXX 請求項nnの回避
What xxxx算出式を変更
How yyy係数を0.125の倍数に変更


492 :デフォルトの名無しさん:2010/05/12(水) 08:05:23
>>474
結局何も新しいこと言ってないんだよな〜

> 「手動で〜するのが面倒だった(動機)」ので「自動で〜する機能を実装した(したかった事=目的)」

結局、散々否定したwhatを書いてるじゃん。
printf を実装した目的を書けってか?
利便性のためという自明な目的なら、いちいちそれを書くのは不毛。
whatを書くだけで十分な場合もある。

> コードを変更した理由として動機を書くのはタコ
> コードを変更した理由として目的を書くのが正しい

動機 = 理由だから、理由に動機を書いてタコな理由が分からん。
目的にこだわる理由を教えてくれ。
理由も動機も目的もニュアンスは同じ。
>>447が指摘済み。

493 :デフォルトの名無しさん:2010/05/12(水) 08:15:27
>>467
単にざっと眺めるだけならannotate, 「この行追加したの誰だ。氏ね」という
気分の時にはblameを使います

494 :デフォルトの名無しさん:2010/05/12(水) 09:29:15
仕様の変更点を探す時はwhy、実装の変更点を探す時はwhatがあった方がいいやね

495 :デフォルトの名無しさん:2010/05/12(水) 10:10:57
>>493
bzrだとannもblameも同じなんだが、他は違うの?
つーか、「この行消した間抜けは誰だ」ってときには使えないし。

496 :デフォルトの名無しさん:2010/05/12(水) 10:15:14
>>492が本物のバカなのはもう疑う余地が無い
問題:「手動で〜するのが面倒だった(動機)」
解法:「自動で〜する機能を実装した(したかった事=目的)」
計算式:Diff
で、解法が書かれていれば計算式の正しさを検証できる
問題と計算式しかない場合、想定していたであろう解法を計算式から予測するしかなく、誰にも検証できない

>printf を実装した目的を書けってか?
当たり前だ
コードからじゃお前以外誰にもprintfを再実装した目的など分からん

>利便性のため
そりゃ動機だ

>whatを書くだけで十分な場合もある。
で?だから何なの?十分な場合もあるから、一辺倒にwhatだけ書いてりゃいいの?

>理由も動機も目的もニュアンスは同じ。
そりゃ大層な無学だな
健康上の理由で辞職する
健康上の動機で辞職する
健康上の目的で辞職する
これじゃ日常会話にすら支障が出るわ
現に出てるし

497 :デフォルトの名無しさん:2010/05/12(水) 10:50:12
文脈もあるよな。ログメッセージ読むってことは多少なり開発に足突っ込んでるだろうから、
簡潔な文章でも他の開発者が「意味わかんねーんだけどナニこれ?」ってならないなら
それでもいいし、けっこう突飛なこととか誤解されそうな内容だったら冗長に書く、
それでいいんじゃないかね。

498 :デフォルトの名無しさん:2010/05/12(水) 11:09:08
>>496
問題と計算式だけあれば、問題が解決されているかどうかで変更の妥当性を検証できるんじゃないの?

499 :デフォルトの名無しさん:2010/05/12(水) 12:09:27
>>498
できない
コードは書かれた通りにしか読めない
そのコードで本当にやりたかった事など誰にも分からない

500 :デフォルトの名無しさん:2010/05/12(水) 12:28:03
>>499
やりたかったことは、その問題を解決したかったということに決まっているじゃないか。
具体的な方法は Diff にある。これで何が不満なの?

501 :デフォルトの名無しさん:2010/05/12(水) 12:43:21
>>469
前任者の履歴コメントなんて見ないよ
何かを知る必要があればdiff見る

502 :デフォルトの名無しさん:2010/05/12(水) 12:45:59
annotation知らん奴が多そうだな

503 :デフォルトの名無しさん:2010/05/12(水) 12:49:30
>>500
いい加減日本語も不自由で人のバグを追ったことも無いタコスケは黙れば?

「手動で〜するのが面倒だった(動機、問題)」ので「〜の条件化では自動で〜する機能を実装した(目的、解法)」
で、お前の作り出した糞の塊であるコミットログには問題しか書かれて無いわけだが
その条件式の必要性と正当性はDiffから読み取れるのか?
こんなシンプルなケースすら想定できないって、どんだけの未熟者が口出ししてんだよ

504 :デフォルトの名無しさん:2010/05/12(水) 12:55:42
>>503
何か後出し来たな・・・。まぁいいか。

その条件式の必要性と正当性は Diff や変更後のファイル自体から読み取れるべきだろ。
自明かもしれないし、自明で無いならコメントが添えられているべき。

ログに「〜の条件下では自動で〜する」と書かれていてもその条件の必要性と正当性は
結局ソースにコメントでも無いとわかんないよね?

505 :デフォルトの名無しさん:2010/05/12(水) 13:07:07
>>504
で?だから何?
結局ソース見なきゃわかんないからログには「手動で〜するのが面倒だった(動機、問題)」だけが書かれていれば十分と主張するの?
もういいよ、お前は生まれ付いての糞転がしで、糞の塊を作り続けるのは本能なんだよな
俺には糞転がしのライフスタイルを改めさせるだけの力は無かったと言う事で終了

506 :デフォルトの名無しさん:2010/05/12(水) 13:37:36
>>505
こちらの主張は、挙げられた例で「手動で〜するのが面倒だった(動機)」にあたるような内容こそ
ログに書くべきなのであって、それを否定するような主張(「〜はタコ」とか)は間違いだと言うこと。

別に「目的、解法」にあたる内容をログに書くことを否定しているわけじゃない。しかしそういった
内容は対象のファイル自体から(ログを追わなくても)読み取れるべきだとも考えているので、
そこがログの要点であるという主張には疑問が残る。

507 :デフォルトの名無しさん:2010/05/12(水) 13:43:11
>>505 無意味なレッテル貼りや煽りをやめればそういう力が付くかもね。がんばれ。

508 :デフォルトの名無しさん:2010/05/12(水) 14:06:49
目的はソースからはなかなか読み取れないと思うなぁ。
ベテランならともかく、若い子の書いたソースなんて
なんでこんなことしてるの?ってのがよくある。
そんなソースに限って、「変数を初期化する」みたいな
無意味なコメントばっかりだったりする。

509 :デフォルトの名無しさん:2010/05/12(水) 14:08:42
>>508
それはソースのコメントで済ませるべき問題であって、ログに書くべきこととは違うんじゃない?

510 :デフォルトの名無しさん:2010/05/12(水) 14:24:44
>>509
人と仕事したこと無い奴が人と仕事するためのルールに口出しするのはおかしいと思わない?

511 :デフォルトの名無しさん:2010/05/12(水) 14:53:45
バグ修正は、
Fixes #xx (BTSの番号) 簡単な記述。
で十分。


512 :デフォルトの名無しさん:2010/05/12(水) 15:09:03
>>495
subversionに文句を言ってくだしあ> <


513 :デフォルトの名無しさん:2010/05/12(水) 15:19:27
コミットの粒度の問題もあって、
新規機能開発で、git, hg の場合、
ローカルな複数のコミットを1つのコミットにまとめて push ってのもある。
CVS, Subversion の場合、ブランチなんだろうけど。


514 :デフォルトの名無しさん:2010/05/12(水) 17:19:27
git-svnの質問いいでしょうか?

ローカルブランチで一通り作業し終わって、リモートtrunkに関連付けたmasterにmergeしgit svn dcommitしました。
こちらの期待としてはブランチでの作業もsvnに上げたかったのですが、
上の方法ではmasterにmergeした分しかsvnにコミットできませんでした。
ようするに「マージした(Merge branch なんとか)」というログと全部マージした1つ分のコミットしかない状態です。
(当たり前といえば当たり前の挙動ですが)

ローカルのブランチでの作業もsvnにコミットしたい場合、どういう開発の流れになるのでしょうか?
git svn branchでリモートブランチを作成し、それにコミットしていくべきなのでしょうか?

また今後はそうするとして、
今あるローカルブランチのログを残したいのですが今からでもsvnでブランチ作成してそこにコミットすることってできないんでしょうか?

515 :デフォルトの名無しさん:2010/05/12(水) 17:39:00
>>514
git svn dcommitするならmergeじゃなくrebaseするべし。

516 :デフォルトの名無しさん:2010/05/12(水) 19:19:08
>>514
master でそのまま作業して dcommit すれば?

517 :デフォルトの名無しさん:2010/05/12(水) 20:08:08
コミットログもソースのコメントも、ここの図のように、
http://doc.bazaar.canonical.com/bzr.dev/ja/user-guide/bazaar_workflows.html#id7
あまりにもおかしいやつは、ゲートキーパーが突っぱねればいいんじゃないの?


518 :デフォルトの名無しさん:2010/05/12(水) 20:09:23
>>495
svn annotate = svn blame = svn praise
気分によってお好みで。


519 :デフォルトの名無しさん:2010/05/12(水) 22:02:47
あ、そういうことか。

520 :514:2010/05/13(木) 13:35:20
git-svnの運用がイマイチわからない・・・

今までsvnだと
機能やissue、チケットごとにブランチ切る&切り替え→実装してコミット繰り返す→trunkに切り替えてマージ
とやってました。

gitでも、チケットごとにブランチ切る&切り替え(git co -b unko_feature)→実装してコミット繰り返す(git add .; git ci)→
masterに切り替えてマージ(git co master; git merge unko_feature)
というようにやってました。

git-svnの場合、
remotes/trunkをlocal_trunkに割り当てて(git co -b local_trunk remotes/trunk 相当?)→
チケットごとにremoteブランチを切って(git local_new_feature co -b remotes/new_feature )→
実装してコミット繰り返す(git add; git ci)→リモートブランチにコミット→(git svn dcommit)→
完了したらtrunkにマージ(git co local_trunk; git merge --no-ff new_feature)→trunkをコミット(git svn dcommit)

でいいんでしょうか。

>>513でも書いたのですが、リモートブランチでなくローカルブランチを作ってマージしてsvnにコミットしても
マージした結果しか残らず、お手軽にローカルでブランチ切って開発というようにはいかないのですが、
こんなもんですか?

リモートブランチはsvn側に記録が残るが、
ローカルブランチはマージだけした場合svn側に残らない(マージしたのがまるごと記録)ということでしょうか?
リモートブランチはsvnに繋がる環境でないといけませんよね?気軽にブランチ切れない気がします。

>>515
git svn rebaseってことですか?git svn rebaseは更新(pull相当)だと思っていたのですが、違うものでしょうか?

>>516
気軽にブランチをバンバン切りたいのです…

521 :デフォルトの名無しさん:2010/05/13(木) 14:28:11
マスタがSubversionなら、気軽にブランチ切っちゃいけないでしょ。


522 :デフォルトの名無しさん:2010/05/13(木) 15:37:55
>> 520
そもそもSubversionは1.5まではマージの記録が残らなかったんだから。



523 :デフォルトの名無しさん:2010/05/13(木) 20:55:42
>>520
>>521の言う通り、Subversionを使う限りはそっちに従わないといけないので、
svnに対しては真っ直ぐな履歴(マージコミットは無し)にしてdcommitしないといけない。
gitとsvnではマージの扱いが違うので、今のところgit-svnはマージの面倒をみてくれない。
Subversion1.5のマージって確かpropsに情報埋め込む感じだったと思うんだけど
gitはコミット同士の親子関係を明確に管理してる。
だからgitでブランチ切ったりしていろいろやるのは自由だけど、最終的に
svnに持っていく時には、svnみたいな履歴(真っ直ぐな履歴)にする必要がある。

git svn dcommitで出来ることは単純。svnに存在しなくてgitにだけ存在するコミットを
(git-svn-idを元に判断して)svnに持って行く。さらにそこにresetする。
git svn rebaseは、同じようにsvnにのみ存在するコミットがあれば持ってきて
rebaseする。
ようは設定したsvnパス(trunkとか)とgitの現在のブランチの同期を図るような感じ。

524 :514:2010/05/14(金) 10:03:17
>>521-523
ありがとうございます。

リモートがsvnだとブランチ気軽に切れないんでしょうか?(ん??何で???)

まっすぐな履歴ということはつまり、リモートブランチをなるべくきらないなら、
trunkにそのままフラットにコミットしていくということでしょうか?

ブランチ切れないと開発しにくくないですか?(git使う意味って??)

> だからgitでブランチ切ったりしていろいろやるのは自由だけど、最終的に
> svnに持っていく時には、svnみたいな履歴(真っ直ぐな履歴)にする必要がある。

これをうまくやるやり方がぜひ知りたいです。
上にも書きましたけど、ローカルブランチをマージしたならマージしたのしかコミットできないので・・・。
(マージした際のそっけないログメッセージは、-mでログを指定するか
mergeした後で --amend で再コミットすればいいと気づいたので解決できそうです)


svn dcommit, svn rebaseはなんとなくわかりました。

>>522
そもそもまだSubversion 1.4使ってる・・・(´・ω・`)

525 :デフォルトの名無しさん:2010/05/14(金) 10:25:39
>>524
Subversionのブランチって(タグでさえも)普通のディレクトリだからね。
Gitとは扱いが違うから、git-svnではGitとSubversionの普通のコミットを
相互にやりとりするぐらいしか出来ない。

>ブランチ切れないと開発しにくくないですか?(git使う意味って??)
SubversionをやめてメインをGitにするなら問題ない。
ていうかSubversionでマージしたりGitでマージしたり、
ごちゃ混ぜにして使ったらおかしなことになりそうだとは思わない?
Git使う意味はあなたに聞きたいね。どうして使いたいの?

>これをうまくやるやり方がぜひ知りたいです。
だからrebaseで真っ直ぐにするんだよ。
まずPro Git とかチュートリアル読んだようが良いと思う
http://progit.org/book/ja/
http://www8.atwiki.jp/git_jp/pages/27.html

526 :デフォルトの名無しさん:2010/05/14(金) 10:54:45
"git svn rebase" じゃなくて "git rebase" とまで書かないと理解していないっぽい。

527 :デフォルトの名無しさん:2010/05/14(金) 11:52:21
アホ過ぎて呆れるわ

528 :デフォルトの名無しさん:2010/05/14(金) 12:44:05
gitにはgitは使えないこの皮肉
これはgit自体がgitである事の証左にもなっている

529 :デフォルトの名無しさん:2010/05/14(金) 13:47:50
うまいこと言ってるつもりなのか。痛いなー

530 :デフォルトの名無しさん:2010/05/14(金) 23:29:53
>>520
> 今までsvnだと
> 機能やissue、チケットごとにブランチ切る&切り替え→実装してコミット繰り返す→trunkに切り替えてマージ
> とやってました。

このルールだと、結合テスト・総合テストの度にマージを繰り返していたってことなのか?
マージが終わったら、"svn rm ブランチ"なのか、放置なのか?
svnでブランチだらけって考えただけで・・・


531 :514:2010/05/15(土) 18:18:46
アホな俺にアドバイスくださり、ありがとうございます!!

>>526-525
Pro Git読んだら、rebase勧められた意味がわかってきました。
あとgit svn rebaseとも混同してましたw

Pro Git - Pro Git 3.6 Git のブランチ機能 リベース
http://progit.org/book/ja/ch3-6.html


Pro Git一通り以前にさらりと読んでいたつもりだったんですが、全然頭に入ってなかったことがわかりました。
実際に使うときにならないとわからないもんです。
頭悪いわ俺・・・

>>530
普通はsvnはブランチがつくりにくい(作るコストやマージしにくい)から
長期のブランチのみで運用するってことですよね?

532 :デフォルトの名無しさん:2010/05/16(日) 08:32:58
>>531
> 普通はsvnはブランチがつくりにくい(作るコストやマージしにくい)から
> 長期のブランチのみで運用するってことですよね?

svnのブランチは、"svn cp DIR1 DIR2"で作るもの。
branchesみたいなディレクトリに作らないと、ブランチなのか何なのか分からない。
branches/ticket/xxx みたいなブランチなら、それはそれでありでは?
でも、とんでもない数にならないか?

長期のブランチってのも、プロダクト、プロジェクトによって違う。
メジャーバージョンで分けたり、安定版・開発版で分けたりする。

Mercurialの場合、この長期のブランチというのは、リポジトリで分けるのがポリシー。
Mercurial本体や、Mozillaがそんな分けかたをしている。

gitはsvnから移行したのが多そうなので、svnを踏襲しているのが多そうに見える。


533 :デフォルトの名無しさん:2010/05/17(月) 21:32:29
>>15
しかしあれを使ってリポジトリを作成するときにFSFSを選択しないと
後で痛い目をみるという

534 :デフォルトの名無しさん:2010/05/18(火) 01:06:32
だいぶ前からデフォルトでFSFSだぞ

535 :デフォルトの名無しさん:2010/05/18(火) 14:44:35
Gitで、リモートリポジトリのブランチに対して git rebase を実行することはできますか。

## リモートブランチからチェックアウト
git checkout -b dev --track origin/dev
## なんかコミットしてpushする
git commit -m "..."
git commit -m "..."
git push
## masterブランチをマージしてrebaseする
git merge master
git rebase master
## 同じことをリモートブランチに対して行いたいんだけど、
## どうしたらいい?



536 :デフォルトの名無しさん:2010/05/18(火) 15:21:28
>>535
>Gitで、リモートリポジトリのブランチに対して git rebase を実行することはできますか。
rebaseしたのをpushしたらいいよ。たぶんFastForwardじゃない、と拒否されるので
ブランチ名に+を付けてpush。
ただし外に公開してるブランチをrebaseしちゃうのはあまりよくない。
他の人が驚くので。そのへんクリアならやってもよいと思うけど。

>git merge master
>git rebase master
mergeしちゃったらrebase意味ないんじゃないか?

537 :デフォルトの名無しさん:2010/05/27(木) 13:18:29
github で、あるリポジトリをフォークしたあとに、オリジナルのリポジトリを反映させるにはどうしたらいいでしょうか。

たとえば
http://github.com/rails/rails.git (オリジナルのリポジトリ)
をフォークして
git@github.com:myname/rails.git (フォークしたリポジトリ)
を作ったとします。
そんで、手元で git clone git@github.com:myname/rails.git を実行して
ローカルにリポジトリを作成しました。
で、そこで作業するのはいいんですが、オリジナルのリポジトリも当然更新されていきます。
その更新を、フォークしたリポジトリに反映させるのはどうしたらいいのでしょうか。


538 :デフォルトの名無しさん:2010/05/27(木) 13:27:22
>>537
remote追加してpush.


539 :デフォルトの名無しさん:2010/05/27(木) 14:05:28
hatしてgood

540 :デフォルトの名無しさん:2010/05/27(木) 15:03:24
>>537
オリジナルをgit remote add してそこからpull
そんでそれを自分とこにpush

541 :デフォルトの名無しさん:2010/05/29(土) 11:16:08
>>538,540
どうもありがとうございます。
具体的な手順としては
git remote add rails http://github.com/rails/rails.git
git pull rails master
git push origin master
であってますでしょうか。

あと、この方法で同期させた場合、ローカルリポジトリに独自のコミットがあった場合、
git pull rails master
はうまくいくのでしょうか。
ローカルリポジトリに独自のコミットがなければうまくいくだろうとは思うのですが、
あった場合に git pull rails master がうまくいくのか心配です。


542 :デフォルトの名無しさん:2010/05/29(土) 11:25:21
>>540
fetchしてmergeないしはrebase


543 :デフォルトの名無しさん:2010/05/29(土) 16:32:01
>>541
ローカルリポジトリに独自のコミットが無いなら単なるミラーになるし
独自のコミットがあればマージされる。コンフリクトしてマージ失敗することも
もちろんある。
てかGitはローカルで誰にも影響与えずにちょちょいと試せるんだから、
テストリポジトリ(テストリモートetc)たくさん作って試行錯誤してみたらいいよ。
あとsvnとかCVSの感覚でいきなり始められるものじゃないから、
一度は腰据えてドキュメント読まないとダメだよ。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html

544 :デフォルトの名無しさん:2010/05/29(土) 16:49:20
テストリモートってあるが、ローカルにbare作っていじり倒せば良い。


545 :デフォルトの名無しさん:2010/05/29(土) 19:02:55
テトリスモードに見えた

546 :デフォルトの名無しさん:2010/06/13(日) 17:58:35
一般的な商用RDB(oracle、Sqlserver)ぐらいの確率でいいんですが、
リポジトリの壊れないフリーのバージョン管理システムはありますか?


547 :デフォルトの名無しさん:2010/06/13(日) 18:10:17
あるよ

548 :デフォルトの名無しさん:2010/06/13(日) 20:01:30
>>546
> 546 名前:デフォルトの名無しさん []: 2010/06/13(日) 17:58:35
> 一般的な商用RDB(oracle、Sqlserver)ぐらいの確率でいいんですが、
> リポジトリの壊れないフリーのバージョン管理システムはありますか?
>
git, Mercurial は、分散型だから、clone自体がバックアップの一種。


549 :デフォルトの名無しさん:2010/06/13(日) 20:04:13
普通に良く使われてるのは壊れないんじゃないか?

550 :デフォルトの名無しさん:2010/06/13(日) 20:08:39
>>549
Subversionの最初のやつ、bdbだっけ、壊れまくったらしいが。


551 :デフォルトの名無しさん:2010/06/13(日) 20:39:44
bdbはリモートディスクで使うとぶっ壊れる。
いまはbdbを使わないFSFSがメインだね。


552 :デフォルトの名無しさん:2010/06/13(日) 21:58:34
CVSの ,v チェックサム入っているように見えなかったんで
コミットログをエディタでいじったりしたんだが、これってまずかったのか?


553 :デフォルトの名無しさん:2010/06/13(日) 22:17:54
この分野はむしろ商用の方が壊れやすいという印象。

554 :デフォルトの名無しさん:2010/06/14(月) 11:08:51
>>552
お勧めはできないけど、独りで使っているなら遠慮なくどうぞ。
後は、CVSスレへ。

555 :デフォルトの名無しさん:2010/06/16(水) 23:11:49
mac portのdarcsがいつまでたっても直る気配ない
乗り換えろってことなのか

556 :デフォルトの名無しさん:2010/06/17(木) 08:19:33
Macからか?

557 :デフォルトの名無しさん:2010/07/07(水) 12:40:33
初歩的な質問なんですが、gitでbranchを切って作業をして、
別件でmasterに戻って作業をする場合は、branch側でどんな状態でもcommitしてから、
masterに戻る…というので良いんでしょうか?

558 :デフォルトの名無しさん:2010/07/07(水) 15:00:52
>>557
そういう時はstashのほうが手軽かも

559 :デフォルトの名無しさん:2010/07/07(水) 19:53:36
開発担当にgitを使わせたいが、commitをどれぐらいの頻度で使わせるべきですか?
促さないとcommitしないし、コメントに何を書けば良いか分からないと文句が出るし、
本当にわけわかめ。

560 :デフォルトの名無しさん:2010/07/07(水) 20:35:09
>>559
とりあえず、そういうのはいまどきの開発者として駄目だから、切ったらいいよ。

561 :デフォルトの名無しさん:2010/07/07(水) 21:07:40
つーかちゃんと教えてやれよ

562 :デフォルトの名無しさん:2010/07/07(水) 21:36:53
帰る前か、忘れたときは次の朝か、1日1回以下しかコミットしないやつ
たくさん居るだろ。

563 :デフォルトの名無しさん:2010/07/08(木) 01:03:17
>>562
チケット切ってそれ単位にさせればいい。
別にチケット管理システム使えと強制はしないけど、残タスクの管理は
なんにしろやるだろ?そのタスク単位にコミットさせればいい。

564 :557:2010/07/09(金) 08:44:19
>>558
おぉ、ありがとうございます。
git stashですね。便利すぎる。

565 :デフォルトの名無しさん:2010/07/09(金) 19:44:48
git stashしたのってオブジェクトとして保存されてる?
違うブランチでgit stash popしちゃった時が怖いから
コミット作ってるなあ

566 :デフォルトの名無しさん:2010/07/13(火) 12:33:14
>>565
>違うブランチでgit stash popしちゃった時が怖いから
あれ、違うブランチでstash popできるのが利点だと思ってたけど違うのかな。

567 :デフォルトの名無しさん:2010/07/13(火) 14:24:37
英語力が貧弱すぎる上に、どうでもいいことなんだけど
checkout よりも checkin の方がしっくりきてしまう…。
でも調べると out が正しいんだよね。

568 :デフォルトの名無しさん:2010/07/13(火) 14:57:29
なんで in のほうがしっくりくる?

569 :デフォルトの名無しさん:2010/07/13(火) 15:05:35
普段聞きなれてるからかと

570 :デフォルトの名無しさん:2010/07/13(火) 15:14:38
ホテルからチェックインする・・・

聞き慣れてないんだが

571 :デフォルトの名無しさん:2010/07/13(火) 15:56:39
出る/出すんだからoutだろ?
何の捻りもなくて理解しやすいと思うが

572 :デフォルトの名無しさん:2010/07/13(火) 16:11:39
ホテルはチェックイン、チェックアウト両方あるけど
飛行機に乗る時はチェックインだけだから
チェックインのほうが使う機会は多い

573 :デフォルトの名無しさん:2010/07/13(火) 16:13:19
>>570は飛行機にも乗らないし、ホテルにも泊らないんだろう

574 :デフォルトの名無しさん:2010/07/13(火) 18:49:10
○ホテルにチェックインする
○ホテルからチェックアウトする

×ホテルからチェックアウトする

って言いたいんじゃ

575 :デフォルトの名無しさん:2010/07/13(火) 20:32:17
      //
    / .人
    /  (__) パカ
   / ∩(____)   あ、ぽこたんインしたお!
   / .|( ・∀・)_
  // |   ヽ/
  " ̄ ̄ ̄"∪

>>567 は廃人

576 :デフォルトの名無しさん:2010/07/13(火) 23:06:20
>>574
てかそれ以外の意図に読み取る方が難しいよな・・・

577 :デフォルトの名無しさん:2010/07/13(火) 23:12:39
ふと思ったけどcheck outの記録を残すVCSってあるっけ?
副次的に残るケースは考え付くけど。
そういう意味じゃcheck〜じゃないよな。

578 :デフォルトの名無しさん:2010/07/13(火) 23:37:54
git reflogはちがうのけ?

579 :デフォルトの名無しさん:2010/07/13(火) 23:41:56
>>577
CVSROOT/history

580 :デフォルトの名無しさん:2010/07/14(水) 01:30:12
>>577
なんでも残せばいいってもんでもないと
宿のチェックアウトは、入った奴が出て行った、っていう意味しかないだろ
残ってたら課金しなきゃいけないしw

主はあくまでもインの方で

581 :デフォルトの名無しさん:2010/07/14(水) 02:39:29
>>578
無いかと思ったらまさにそれか

582 :デフォルトの名無しさん:2010/07/14(水) 09:52:32
>>580
手続きを伴わなければチェックアウトという言い方はしないよ
#飛行機でチェックインは言ってもチェックアウトとは言わないのはその為

おそらく昔のVCS(RCSとかSCCSとか)でファイルを持ち出す時にロックの手続きを
行っていたからチェックアウトという呼び方になって、その名残なんじゃないかな

583 :デフォルトの名無しさん:2010/07/14(水) 10:26:31
git reflogなんでも記録残っててすごいな
やべ、間違った・・・ってときもとりあえずgit reflog
git gcとかpushする前なら戻せるのびっくりしたわ

584 :デフォルトの名無しさん:2010/07/16(金) 14:07:43
gitで何か新しいことをやろうとすると、
なぜかコミットを失ってわけわからん状態になるので
毎回reflogで救い出してます。reflog様々ですね

585 :デフォルトの名無しさん:2010/07/16(金) 16:59:41
>>584
なんで、そんな状態になるのか調べたほうが早くないか?

586 :デフォルトの名無しさん:2010/07/16(金) 22:56:18
>>584
gitで新しいことをやろうとするまえに、bzrあたりでコミットしておけばいいんじゃね?

587 :デフォルトの名無しさん:2010/07/17(土) 08:58:41
bzr-git使えばいいんじゃね?

588 :デフォルトの名無しさん:2010/07/17(土) 09:50:03
最初からBazaarを使えばいいんじゃね?

589 :デフォルトの名無しさん:2010/07/17(土) 09:59:54
賢い人は最初から分かってるよね。

590 :デフォルトの名無しさん:2010/07/17(土) 11:57:26
C++の話(本当にあった怖い話)
http://www.slideshare.net/Isoparametric/c-horror-kai


中身はバージョン管理してないとかそういう話

591 :デフォルトの名無しさん:2010/07/17(土) 12:58:04
>>590
SVNスレの方にはSVN使ってても先祖返りされたっていう実例もあるし、VSS以前の話じゃない?

592 :デフォルトの名無しさん:2010/07/17(土) 14:21:47
>>590 のプレゼンした人のブログにあった記事ワラタww

VSSが相変わらずフルボッコすぎる件について - 神様なんて信じない僕らのために
http://d.hatena.ne.jp/Isoparametric/20100428/1272405617


> 「ゲームコーディング・コンプリート」より引用。
>
> 常識的に考えて嫌われすぎだろ……。
>
> Microsoft製Visual SourceSafe
>
>  Visual SourceSafeはMicrosoftのVisual Studioで使われているソースリポジトリである。
> 「安かろう悪かろう」の良い例だ。
>
> 多くの人がこの製品に惹かれるのは、GUIインターフェイスが使いやすく、
> セットアップがとても簡単だからだ。タイプするのが遅くなければ、 10分で起動できる。
>
>  SourceSafeの一番の問題点は、ソースリポジトリをどうやって格納するかだ。
> リポジトリが格納された共有ファイルを探ってみると、 AAAAAAAB.AAAとかAAACCCAA.AABのような
> 奇妙な名前のついたファイルからなる大きなツリー構造のデータディレクトリがある。
> こうしたファイルの中身はプレーンテキスト(バイナリ化されていない)かそれに近い形だ。
> だからこの奇妙な名前のつけ方はセキュリティ上の理由からではない。
> 理由をご存じの方はメールで教えてほしい。気になって仕方がない。
>
>  それぞれのファイルは、リポジトリ内のファイルの、前のリビジョンとの差分を保持する。
> ファイルを改訂すれば新しくSourceSafeのファイルを作り、例の変な名前をつける。
> 注意して見ていると、ソース変更が1文字程度の簡単なものであれば、作られるファイルの多くはかなり小さいとわかる。
> それなのに、SourceSafeがネットワークドライブに確保するスペースの量は、控えめにいっても容認できる限界を超えている。
>
(続く)

593 :デフォルトの名無しさん:2010/07/17(土) 14:24:27
>  速度面でも深刻な問題がある。小さなプロジェクトでさえ数百のファイルの規模になり、
> 大きいプロジェクトにいたっては何十万ファイルにもなり得る。
> SourceSafeはデータファイルをリポジトリディレクトリ構造に格納するので、
> ファイルの開閉にかかるアクセス時間は極めて長く、プログラマは最新のファイルかどうかを
> チェックするだけでも果てしなく待たされることがある。
>
>  SourceSafeはブランチをサポートしておらず(ブランチについてはあとで触れる)、
> 枝分かれさせたかったらツリー全体の完全なコピーを作らなければならない。お話にならない。
>
>  SourceSafeにリモートでアクセスしようなどと思ってはならない。
> 何千ものファイルをのろのろしたインターネットを介して検索するなどもってのほか。
> T1回線でもダメだ。最終的にSourceSafeのファイルインデックスデータベースは動かなくなり、
> ちょっとした分析ユーティリティにも降参し、やり直しだといってくる。
> 私は以前、壊れたデータベースでプロジェクトを乗り切ったことがあるが、
> 壊れた部分の影響が、もはや必要のない古いバージョンのファイルだけにとどまっていた。不幸中の幸いだった。
>
>  SourceSafeには自ら壊れる癖もある。リポジトリ全体を役立たずの不可解なファイルの山にする。
> これは特に、サウンド、テクスチャ、ビデオなどの大きなバイナリ資源を格納するときに起こる。
>
>  まだSourceSafe以外のものを使おうという気になってなければ、こういいたい。
> よく調べてほしい。Microsoft自身が使わないという噂を耳にしたことがある。
> もちろん単なる噂にすぎないかもしれないが、他の選択肢も検討してみる余地はある。
>
> バージョン管理システムの紹介で、ダメだししか書いてないよー!

元ネタ
Amazon.co.jp: ゲームコーディング・コンプリート 一流になるためのゲームプログラミング: Mike Mcshaffry, 手島 孝人, 山下 恵美子, 依田 光江, 大貫 宏美, 廉 典子, 田中 幸, 宮本 寿代: 本
http://www.amazon.co.jp/dp/4797358432

594 :デフォルトの名無しさん:2010/07/17(土) 14:25:28
悪い引用中のスペースが崩れた・・・

専ブラ用ポップアップおいとく >>592-593


595 :デフォルトの名無しさん:2010/07/18(日) 00:36:31
Visual SourceSafeは、MS的にも既に終了したプロダクトだろ。
だから、MSDNのVS 2010からTeam Foundation Serverをただで使わせるようにしたんだし。

596 :デフォルトの名無しさん:2010/07/18(日) 00:40:07
>>595
それって結局VSSをマシに作り直した的なものだったりしないのかな?

597 :デフォルトの名無しさん:2010/07/19(月) 02:16:16
クラサバ方式になってる時点で全くの別物

598 :デフォルトの名無しさん:2010/07/19(月) 02:42:55
その悪評高いVSSはクラサバじゃないのか?
クラサバじゃないのにどうやってリポジトリ共有するの?
p2pなのかな?

599 :デフォルトの名無しさん:2010/07/19(月) 02:45:31
調べたらVSS6.0まではファイル共有で運用だったのかw
それが原因でファイル壊れるとかワロタ

とはいえ2000年頭のかなり昔の話だな。今はさすがにないだろ

600 :デフォルトの名無しさん:2010/07/19(月) 08:21:59
調べるも何も、>592-593に書いてあるのに……
おまけに>595にも終了したって書いてあるのに……

601 :デフォルトの名無しさん:2010/07/19(月) 09:14:48
MS codeplexはhg対応したみたいだけど、gitはどうするのかな?

602 :デフォルトの名無しさん:2010/07/19(月) 15:57:55
オープンソースは悪だってずっと言ってたけど、変わるもんだねぇ

603 :デフォルトの名無しさん:2010/07/19(月) 17:33:13
世界中の好きモンが、世界中のユーザーにあーだこーだ言われながら作っていくんだから
完成度はメーカー製の比じゃないと思うがね。

残念ながら Linux に関しては微妙なところだが。

604 :デフォルトの名無しさん:2010/07/20(火) 01:51:43
codeplexもそうだけどgoogle codeもDVCSでhgしか対応していないんだよね。
bzrをさわるきっかけが無い理由の1つ。

605 :デフォルトの名無しさん:2010/07/20(火) 01:54:12
bzr-hgはbzr-gitやbzr-svnに比べて遅れてたけど、今は使い物になるのかな?
bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。

606 :デフォルトの名無しさん:2010/07/20(火) 02:20:55
お前らよくそんなに多種多様なVCS使えるな

607 :デフォルトの名無しさん:2010/07/20(火) 02:32:25
>>605
Pythonがhgに移行する(した?)んだからbzr-hgが実用じゃないと困るんじゃないの?

608 :デフォルトの名無しさん:2010/07/21(水) 01:32:51
ところで分散バージョン管理のpush/pullは、なんであんなに
システムごとに概念が違うんだ。

609 :デフォルトの名無しさん:2010/07/21(水) 02:23:44
バージョン管理ごときに脳細胞1つも使いたくない
何、管理システム乱立させてんだよ。戦国時代ごっこか?
とっとと、これ使っておけばおkって物だせよ
いつまで待たせんだよ

610 :デフォルトの名無しさん:2010/07/21(水) 02:31:35
>>609
明らさまにそう言う人はあまり居ないが、大半はそうなんだろうな。
これっぽっちもドキュメント読まないで2chで質問してる人が多いもの。
ある意味インフラだからなー。

611 :デフォルトの名無しさん:2010/07/21(水) 05:21:43
>>605
> bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
> 操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。

え、マジ?
それいいな

とりあえずgit採用しておいて、gitでのマルチバイトの不安なWindowsからはbzr-gitで操作とかも可能なのか
それはすごい

>>609
いや、実際そうですよ

中央集権ならSubversion一択、と思っていた時期が私にもありました・・・

分散バージョン管理使ってみたら、もうもどれないな。
もちろん細かい不都合は多々あるんだがね。
Windowsとの連携とかマルチバイトがらみの話とか、マルチバイトとか、マルチバイトとか

612 : [―{}@{}@{}-] デフォルトの名無しさん:2010/07/21(水) 06:25:43
>>611
>>588

613 :デフォルトの名無しさん:2010/07/21(水) 07:18:01
>>612
あ、、、

確かに

614 :デフォルトの名無しさん:2010/07/21(水) 07:49:09
bzrとhg同じpythonだから仲良く出来ないのかな?これじゃあ・・・
http://wiki.bazaar.canonical.com/BzrVsHg
http://mercurial.selenic.com/wiki/BzrVsHg

615 :デフォルトの名無しさん:2010/07/21(水) 15:07:52
>>608
>ところで分散バージョン管理のpush/pullは、なんであんなに
>システムごとに概念が違うんだ。

後学のために詳しく説明してください。お願いします。

616 :デフォルトの名無しさん:2010/07/21(水) 15:20:25
何で自分で調べないの?

617 :デフォルトの名無しさん:2010/07/21(水) 18:29:38
脳細胞1つも使いたくないんでしょw

618 :デフォルトの名無しさん:2010/07/21(水) 19:48:56
>>614
hgさんは、日本語ファイル名の対応に対する開発者のメール見て脱力したから
俺は仲良く出来ないなぁ。マルチバイト圏に対する考慮というか理解が欠けすぎ。
>>615
むしろ同じものを作りたくないから違って普通じゃ無いかと。
どこをチューニングするかって目的意識の違いで設計が変わっているっぽいね。

619 :デフォルトの名無しさん:2010/07/21(水) 23:03:58
このスレ日本語ファイル名の対応に対する開発者のメール見て脱力した人よく見るよね

TOMOYO Linuxの人みたいにがんばって対応しないといけないんだろうな・・・

620 :デフォルトの名無しさん:2010/07/21(水) 23:34:58
>>609
http://www.ericsink.com/entries/veracity_early.html

621 :デフォルトの名無しさん:2010/07/22(木) 02:03:20
>>619
gitやhgしかなければそうなんだろうけど
...bzr

実際使ってみれば、Bazaar別に悪くないのに
マルチバイト圏の人間が盛り上げなくてどうするんだろ

ガラパゴス恐怖症なのかもね。わからなくもないけど

622 :デフォルトの名無しさん:2010/07/22(木) 11:07:25
>>605
bzr-gitとbzr-hgどっちもpushできないって書いてあったんだけど・・・

623 :デフォルトの名無しさん:2010/07/22(木) 11:17:40
>>622
bzr-gitはdpushはできる。bzr-hgはまだ使ってないから知らない。

pushとdpushの違いは、相手側のフォーマットとこちらのフォーマットの間で
ラウンドトリップができるかどうか。

pushの場合はラウンドトリップができる(bzrのリビジョンを向こうに置いても、pullすれば
bzrのリビジョンIDが復元できる)ので、bzrのリビジョンを全く修正せずに
pushする。bzr-svnでは、svnのversioned propertyにbzrのリビジョンIDや
ファイルIDを付与することでラウンドトリップを実現している。

dpush の場合はラウンドトリップができない(一度pushしてpullすると別のリビジョンIDに
なってしまう)ので、手元のリビジョンを向こうのフォーマットに合わせて作り直す。
例えば、bzr-gitの場合、bzrのリビジョンidを "git:<sha1>" という形に書き換えて、
bzr側に「gitのどのリビジョンに対応するか」という情報を保存する。

一応、gitのコメントの最後にbzrのリビジョンIDをつけることでpushを実現する方法も
開発されてたと思う。その場合、gitで普通にログを見るとbzrのリビジョンIDが見えちゃうけど。

624 :デフォルトの名無しさん:2010/07/22(木) 11:46:36
bzr-svnの一発目は軽いの?
git,hgともsvnクライアントとして使おうとすると最初のcloneが重くて。

625 :デフォルトの名無しさん:2010/07/22(木) 11:51:44
>>624
bzr-svnも重い。こればかりはsvnプロトコルの問題だからなぁ…

オープンソースのプロジェクトなら、Launchpadでimportしてしばらく待っておけば
ミラーが出来上がるので、そこから作業始めれば楽。
社内利用なら、リポジトリのコピーをローカルに持ってきて、ネットワークを通さないで
bzr-svnを使うと速い。

626 :デフォルトの名無しさん:2010/07/22(木) 11:54:23
Launchpadってユーザ作ってプロジェクト簡単に作れるの?
github, bitbucketみたいな勝手にforkとは文化が違うみたいなんだけど。

627 :デフォルトの名無しさん:2010/07/22(木) 11:57:01
>>626
プロジェクトは簡単に作れるよ。
forkを作るときは、 lp:~ユーザー名/プロジェクト名/ブランチ名 という感じでブランチを作る。
プロジェクトを用意するまでもないときには、プロジェクト名のところに +junk って書けば
プロジェクトに属さないブランチを登録できる。

628 :デフォルトの名無しさん:2010/07/22(木) 12:33:59
hgのここ重宝するんだけど、bzrもあったらうれしいな。
http://mercurial.selenic.com/wiki/GitConcepts


629 :デフォルトの名無しさん:2010/07/22(木) 15:40:16
bzr ってやたら重くない?


630 :デフォルトの名無しさん:2010/07/22(木) 16:03:17
>>629
別に?

631 :デフォルトの名無しさん:2010/07/22(木) 16:51:04
Bazaar Explorer は何かと重い。

632 :デフォルトの名無しさん:2010/07/22(木) 18:25:15
ちょっと大きなリポジトリを clone するとえらい待たされるような


633 :デフォルトの名無しさん:2010/07/22(木) 20:33:34
煙草でも吸ってればいいと思う

634 :デフォルトの名無しさん:2010/07/22(木) 21:26:02
なら自分は嫌煙厨なので煙草が必要なbzrは捨てだな

635 :デフォルトの名無しさん:2010/07/22(木) 21:51:44
bzr の clone(branch) は tree を再構築するから多少遅いね
gitやhgはレポジトリ丸ごとコピーな分速い
分散型の宿命で clone は SVN の checkout と比べたら、どれも十分遅いけど
最初の1回だけだから、それほど気にならないな

636 :デフォルトの名無しさん:2010/07/22(木) 22:04:19
hgのcloneは基本は丸ごとだけど、-r でリビジョン、1.5からは -b でブランチを指定してcloneが出来る。
firefoxやopenofficeみたいな弩級のリポジトリはタグを指定してcloneしてからpullをちまちまやった方が安全。
cloneは途中で失敗すると最初からやり直しだから。

637 :デフォルトの名無しさん:2010/07/22(木) 22:07:43
openofficeでかいからbundle配布しているみたいだね。
http://wiki.services.openoffice.org/wiki/Mercurial/Getting_Started


638 :デフォルトの名無しさん:2010/07/22(木) 22:57:58
>>636
その辺りはgitもbzrも同様だよ。
機能的にはどれも同じようなものが揃ってる。

639 :デフォルトの名無しさん:2010/07/22(木) 23:01:28
遅いっていっても1時間とかかかるわけじゃないし、そんなに問題じゃないでしょ。

640 :デフォルトの名無しさん:2010/07/23(金) 02:10:18
gitとhgは機能的に似たようなもんだけど、bzrはちょっと感覚が違うなぁ。

641 :デフォルトの名無しさん:2010/07/23(金) 03:29:49
Inkscape を clone するときなんか多少どころの遅さじゃなかったなー。 > bzr


642 :デフォルトの名無しさん:2010/07/23(金) 08:07:54
>>635
svnのcheckoutは.svnにコピーを作るから十分遅いでしょ。
hgのcloneは-Uオプションでファイルを展開しないというのもあるので、ある意味svnのcheckoutより速い。

643 :デフォルトの名無しさん:2010/07/23(金) 08:08:55
bzrって昔は遅かったから、リポジトリフォーマットを新しいやつにして、bzrも2.0以降を使わないと
遅くなると思う。
今LaunchpadのInkscapeブランチを見たら、「An upgrade of this branch is in progress.」って
書いてあったから、もうすぐ新しいフォーマットが使われるようになると思う。

問題は、新しいフォーマットが実験的にサポートされたのが1.16からなのに対して、
Debian lennyでも標準のパッケージは1.15なんだよな。自分で新しいやつを入れないと
いけない。

644 :デフォルトの名無しさん:2010/07/23(金) 08:11:32
>>642
履歴がかなり古いプロジェクトを除いたら、hg/git/bzrの方が速いよね。
gitは --depth っての使ったら履歴を途中から持ってこれるから、履歴の古い
プロジェクトでも強い。Bazaarにはまだ各種コマンドが履歴がちょん切れても
動くようにしている最中で、--depth機能は無い。

645 :デフォルトの名無しさん:2010/07/23(金) 08:38:06
>>644
hgも履歴の途中のcloneのプランはあるんだけどね。
http://mercurial.selenic.com/wiki/ShallowClone
Google Summer of Codeでやんのか。


646 :デフォルトの名無しさん:2010/07/23(金) 10:54:10
>>605
> bzr-hgはbzr-gitやbzr-svnに比べて遅れてたけど、今は使い物になるのかな?
> bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
> 操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。
これって、EUC-JPやlatin1でもいけるってこと?

647 :デフォルトの名無しさん:2010/07/23(金) 12:23:24
>>643
アップデートの多いアプリは、標準パッケージはほとんど使わないな。
古くて使ってられん。

648 :デフォルトの名無しさん:2010/07/23(金) 16:39:26
最近の bzr は bzr log も速くなってるのかな?
Emacs のソースツリーで bzr log --limit=4 FILE とかやると 1 分以上待たされるw


649 :デフォルトの名無しさん:2010/07/23(金) 16:59:12
>>643
lenny-backportsなら2.0.3だよ
http://packages.debian.org/search?keywords=bzr

>>647
Debianは特にリリース間隔長いからね…

650 :デフォルトの名無しさん:2010/07/23(金) 18:22:02
>>614
設計方針からして違うんだから仲良く出来るはずがない。
bzrはクソすぎて理解できん。
GuidoがbzrよりMercurialの方がSubversionに近いと言っているのをBazaarMLで頭がおかしいと言っているのを見て
bzrがクソな理由がよく理解できた。

651 :デフォルトの名無しさん:2010/07/23(金) 18:44:54
Bazaarの開発者もMercurialの開発者もPythonのコミュニティ内では仲良くしているよ。
>>650
先にMercurialを理解してしまったせいで、その先入観がBazaarの理解を妨げているんじゃない?
Bazaarはブランチをうまく管理できないユーザーにsvn coと同じチェックアウトを利用して
push/pull 無しに update/commit だけで作業することもできるし、
ブランチにURLが対応するのもSubversionと似てるよ。

652 :デフォルトの名無しさん:2010/07/23(金) 19:23:35
Mercurialの場合Subversionでのブランチはこんなのを意味するんだけど
http://hg.mozilla.org/releases/mozilla-1.9.1/
http://hg.mozilla.org/releases/mozilla-1.9.2/


653 :デフォルトの名無しさん:2010/07/23(金) 19:30:54
>>652
ブランチどころかリポジトリも別れちゃってるから、両方cloneしたら同じリビジョンを
2回ダウンロードする必要が発生しない?

654 :デフォルトの名無しさん:2010/07/23(金) 19:39:38
>>653
それで何が問題?
容量のことなら、Mercurialの場合あまり気にしていないけど。
Mozillaの場合、CVS文化のままっぽいから名前付きブランチが付いていて例として良くないけど。

655 :デフォルトの名無しさん:2010/07/23(金) 20:17:59
>>654
ディスク容量よりも、ダウンロード時間やネットワーク負荷の方が問題だな。

656 :デフォルトの名無しさん:2010/07/23(金) 20:35:34
Mercurialのブランチのポリシー、こっちの方がいい。
http://mercurial.selenic.com/wiki/DeveloperRepos
開発者はcrewを持ってくるし、
一般ユーザで上のDebianの例じゃないけど少しでも早く安定版が使いたい人はstableを持ってくる。


657 :デフォルトの名無しさん:2010/07/23(金) 20:51:50
>>653
マジで? それってsvnと変わらなくないか。。。?

658 :デフォルトの名無しさん:2010/07/23(金) 21:01:16
>>657
Mozillaの場合、マルチヘッドにもなっているっぽいのであんまり良い例じゃなかったね。
hgはgitのリモートブランチという概念も中央リポジトリという概念も無いから
別にネットワーク越しに同期する必要も無いし。

659 :デフォルトの名無しさん:2010/07/23(金) 21:44:30
>>657
どうしても2回pullがいやっていうんなら、手持ちのリポジトリを合体させておけばいい。

660 :デフォルトの名無しさん:2010/07/23(金) 23:54:00
>>628
あー、こういうのいいね。
同様なツールの他のものとの構造の比較みたいのってはっきりいって理解の妨げになりやすい
すごく助かるわ

よく参考書でも複数買って照らし合わせたら異なる角度で書かれていてわかりやすいみたいな現象

661 :デフォルトの名無しさん:2010/07/24(土) 00:00:03
git の cloneメチャ早くてびっくりする。githubで大き目のプロジェクトcloneしても、やたら早い
Subversionをdisるだけはあるわw

圧縮して固めて一括転送してるのか?あれは

662 :デフォルトの名無しさん:2010/07/24(土) 13:01:51
Bazzarは一番シンプルな動作の組み合わせで分散バージョン管理を実現してると思うがなあ。
単機能コマンドを組み合わせて複雑な目標を達成するunix的というか。

663 :デフォルトの名無しさん:2010/07/24(土) 13:19:23
好きなの使えばいいじゃん。
git が流行ってる理由がよくわからんが。

664 :デフォルトの名無しさん:2010/07/24(土) 13:23:01
>>615
・bzrのpush/pull
ブランチの履歴を全く同じ状態にする。
送り元のみがマージされていないチェンジセットを持った状態でないと実行できない。

こんな感じ?

・mercrialのpush
・mercrialのpull
・gitのpush
・gitのpull

について、誰か頼む


665 :デフォルトの名無しさん:2010/07/24(土) 13:32:16
お前らコマンドラインで使ってますか?

833 名前:デフォルトの名無しさん[sage] 投稿日:2010/07/24(土) 13:19:42
LinuxでRubyのなんちゃらを開発してる人ってさ、Gitのクライアント何使ってんの?
まさかコマンドラインで頑張ってるの?



666 :デフォルトの名無しさん:2010/07/24(土) 13:33:45
>>662
> 単機能コマンドを組み合わせて複雑な目標を達成するunix的というか。

実装の話だけで言えばgitがそんな感じだぞw

667 :デフォルトの名無しさん:2010/07/24(土) 14:31:13
>>665
gitはコマンドラインでの使い勝手がいいから、linuxならコマンドラインで十分いけるな。
diffの時にいちいち | less つけなくていいところとか他も見習ってほしい。

Subversionの場合はTortoiseつかわないとやってられない。
リモート操作の時とかやたらパスが長くなるのとか、コマンドラインで動作が遅いとイライラするし。
もちろんTortoiseSVNの出来がよくて安定してるからってのもあるけど。

668 :デフォルトの名無しさん:2010/07/24(土) 14:41:16
>>667
でもログはgitkでみちゃう。

669 :デフォルトの名無しさん:2010/07/24(土) 14:56:45
>>666
bzrはdebian/ubuntu的というのが敷居の高さを感じさせる

670 :デフォルトの名無しさん:2010/07/24(土) 14:57:55
svnはTortoiseSVNが十分成熟してるからコマンドライン使わないな。
TortoiseBBR他のは日本語パスの扱いが微妙に怪しかったりするので
コマンドラインから使ってる。

671 :デフォルトの名無しさん:2010/07/24(土) 15:30:53
>>664
・hgのpull/push
incoming/outgoingで確認した結果を実行する。
pushは送り先でマルチヘッドになる場合怒られるが強制的に作ることも可能。
TortoiseHgに「Push new branch」という新たなオプションが付いたので変わったかもしれない。

672 :デフォルトの名無しさん:2010/07/24(土) 15:46:53
俺もgitでログみるときはgitkだな

--graphとかもっと見やすくならんの?
サブピクセルみたいにコンソールにもっと詰め込む技術の開発が必要

673 :デフォルトの名無しさん:2010/07/24(土) 16:20:50
>>667
Windowsでもコンソールだけでいける。
msysgitのエクスプローラの右クリックでコンソールが立ち上がるのが凄い便利。

674 :デフォルトの名無しさん:2010/07/24(土) 16:40:01
自社内もしくは個人レベルのプロジェクトなら好きなの使えるけど
常駐先とか、他社が入った場合は、難しいよなぁ。
話しあって決められる場合はまだいいけど、指定されている場合もあるし。

675 :デフォルトの名無しさん:2010/07/24(土) 16:51:16
>>674
>>605


676 :デフォルトの名無しさん:2010/07/24(土) 18:54:51
gitをコンソールだけで弄っている人に聞きたいんですけど、
履歴の把握はどうしてます?
ブランチとかたくさんあるとこんがらがったり、rebaseとかmergeするときに
コンソールだけだとわけわかんない・・・


そういや、msysgitってマルチバイト大丈夫になったんだっけ?

677 :デフォルトの名無しさん:2010/07/24(土) 19:17:31
>>676
>>672

678 :デフォルトの名無しさん:2010/07/24(土) 19:21:25
>>676
gitk --all

679 :676=672:2010/07/24(土) 19:53:52
わるい、今はgitk --all使っているんだ

ごめん、IDないとわからんな
おれ >>672 なんだ orz


ただ、gitkだとUnix系ならX入ってないと見れないよね?違うかな?
Cygwin版のgitkなんかのGUIツールは文字化けするから、
どうせと思って動かしている仮想環境のLinuxでgitk立ち上げたら文字化けは問題ないんだけど、
ほぼそれだけのためにX立ち上げてるのがねえ
ちょっと不満なんだ

それがなければ、sshでターミナルでつなぐだけですむのに、と思って
ちょっとLinux経験あさいから、もっといい方法知っている人はぜひつっこみいれてほしい

680 :667:2010/07/24(土) 20:27:15
>>676
仕事でgit-svn中心で使ってたからあんまり複雑な履歴は扱ってないな
MacだとGitXってクライアントがなかなか見やすかった。

681 :デフォルトの名無しさん:2010/07/24(土) 20:37:04
>>676
git log --graph --oneline --decorate

682 :デフォルトの名無しさん:2010/07/24(土) 21:13:10
>>681
ありがとう、見やすくなった。
ざっと見るだけならこれでいいか。

こんなのも試してみた。
formatの%dがgit 1.6は対応してないが。1.7だと行けたが
git log --graph --date=short --pretty=format:'%Cgreen%h%d %cd %Cred%cn %Creset%s'

683 :デフォルトの名無しさん:2010/07/24(土) 22:08:18
Macでいいならgitxが便利。gitkとかクソ。

684 :デフォルトの名無しさん:2010/07/24(土) 22:38:08
>>683
履歴の探索に関してはgitkもgitxも同じに見えるんだが…

685 :デフォルトの名無しさん:2010/07/25(日) 19:18:42
>>684
ああごめん、大筋の機能は同じだけど、使いやすさと美しさではgitxの圧勝。しょうがないけど。



686 :デフォルトの名無しさん:2010/07/25(日) 20:17:50
cygwinのgitkクソすぎる。不安定すぐ固まるし。

687 :デフォルトの名無しさん:2010/07/25(日) 21:10:54
用途次第じゃね?

boostを展開したディレクトリをSVNでコミットしようとすると1日かかるんだが、小分けにすると5分で終わる。
並列処理でかえって遅くなってるよな。

こんな使い方するほうが悪いんだろうけどさw

688 :デフォルトの名無しさん:2010/07/25(日) 22:11:34
gitのレポジトリ構造にbzrのUIなら文句無いんだけどなぁ

689 :デフォルトの名無しさん:2010/07/25(日) 23:22:04
レポジトリの中身はユーザが意識しなくてもいいのが正道だと思うが

690 :デフォルトの名無しさん:2010/07/25(日) 23:25:04
SVNはリポジトリが手元に無くて理解しにくいと思うが

691 :デフォルトの名無しさん:2010/07/25(日) 23:32:30
中身はユーザが意識しなくてもいいってのは誤解を呼びそうだな。
レポジトリのフォーマットは、ユーザが意識しなくてもいいってのが言いたいこと。

692 :デフォルトの名無しさん:2010/07/25(日) 23:36:10
>>690
手元にないのが嫌ならローカルに作ればいいじゃない

693 :デフォルトの名無しさん:2010/07/26(月) 12:23:28
msysgit と TortoiseGit 使ってるけど、日本語コミットログ絡みでmsysgitコマンドが
うまく動かない場合を除いて、たいていコマンドラインでやっちゃうようになった。

ログ見るのはコマンドラインとGUIの併用だな。

つーかgitとSearchIndexerとカスペの相性災厄。

694 :デフォルトの名無しさん:2010/07/26(月) 20:31:27
searchindexerと相性っつーか関連があったのか
やたらgit使ってると重くなるときあるなあと思ってたけど
偶然じゃなかったってことか

695 :デフォルトの名無しさん:2010/07/26(月) 20:38:49
msysGit の UTF-8ファイル名対応版を作りました。
一応、TortoiseGit からきちんとUTF-8ファイル名を扱えることを確認済み。
http://tmurakam.org/git/
本家にもパッチ送っておいたけど、取り込まれるかな、、、?

696 :デフォルトの名無しさん:2010/07/26(月) 20:41:22
神じゃ
神が降臨なされた

697 :デフォルトの名無しさん:2010/07/26(月) 21:14:59
hgのfixutf8の強力なライバル出現。
fixutf8の場合リポジトリ毎に有効にするかしないか選択できるんだけど。

698 :デフォルトの名無しさん:2010/07/26(月) 22:51:48
素晴らしいね。早く分散バージョン管理御三家にもsvn並の
マルチバイト対応がされる日が来ることを祈るよ。

699 :デフォルトの名無しさん:2010/07/26(月) 23:08:06
>>695
神キターオワタ\(^o^)/



700 :デフォルトの名無しさん:2010/07/26(月) 23:08:28
わるい、オワタ の文字消し忘れた

701 :デフォルトの名無しさん:2010/07/26(月) 23:51:29
ちょw 神は死んだwwww

702 :デフォルトの名無しさん:2010/07/27(火) 00:44:27
終わっちゃったよ・・・

703 :デフォルトの名無しさん:2010/07/27(火) 01:14:07
>>695
使ってみました。

全体的にUTF-8のcygwin gitと問題になっている状況が改善しないところがあったので報告
こちら側で何か変なところがあるのかもしれない

・TortoiseGitでそちらのmsysGitのgitパスを設定しmsysGitのバージョンが出ることを確認
・TortoiseGitのコミットダイアログでは、マルチバイトのファイル名は化けず、diffアプリもちゃんと呼べる
・コミット時のProgressウインドウではファイル名表示が化ける(コミット自体は成功)
・TortoiseGitのログ表示でマルチバイトのファイル名が文字化けした。コミットログは文字化けしない。
 文字化けファイル名はdiffアプリに正しく渡すことが出来ない
・そちらのmsysGit UTF-8付属のgitkは、同様にファイル名とdiff表示の中身がUTF-8のファイルが文字化け。
 コミットログはOK
・同じく付属のGit GUIは、マルチバイトファイル名の表示やindexに追加、コミットまでが無事に行けました

捕捉
・msysGit UTF-8でコミットした日本語ログはcygwin gitでもちゃんと見られた
・cygwinのgitkではファイル名は化ける。diff表示ではファイルの中身がUTF-8のものは見られる。SJISは化ける


gitkはcygwinのUTF-8でもおかしいのでtkの問題なのかな。
ファイルの中身がUTF-8なものが化けてSJISは見られるのがよくわからないけど
GitGUIの設定ウインドウ見る限り、.gitconfigは見てくれてるみたいのようだし

704 :703:2010/07/27(火) 01:47:32
>>695
ちょっと状況がよくわからないが少し追加

・msysGit UTF-8をファイラーのコンテキストメニューの"Git Commit Tool"もしくは、"Git GUI"からGit GUIを起動し、
 そこから、メニューのブランチの履歴を選んでgitkを起動した場合、
 ファイル名は文字化けするが、diff表示の中身がUTF-8のファイルは文字化けなし。SJISは文字化け
 オプションの設定を見るに、HOMEの.gitkをちゃんと読んでくれているよう
・逆にコンテキストメニューの"Git History"からgitkを立ち上げた場合は、
 HOMEの.gitkを読んでくれず >>703の通り、
 ファイル名は文字化けし、diff表示の中身がUTF-8のファイルは文字化けする。SJISは文字化けしない
 というdiffだけ逆の状態。
 gitkのオプションで設定を変えても、保存されない

 (一番目)Git GUIから立ち上げた場合はgitの子プロセスでgitkが起動していて、
 (二番目)gitkをそのまま立ち上げた場合はsh.exeから--login オプション起動している点も気になる


cygwin 1.7とgitが既に入っていて、インストール時にshell extentionにGit Cheetah選んだんだけどそれのせいなのかな
ただ、Process Explorerで見る限りはmsysGit側のexeが立ち上がっており、
cygwinのexeが間違って起動されていることはないみたい

705 :695:2010/07/27(火) 03:04:41
どうもありがとうございます。

TortoiseGit 側は文字列が ANSI で出力されてくることを期待しているので、UTF-8 を ANSI に
変換して出力するような修正をいれているんですが、ログが文字化けするということはまだ直しきれて
ない箇所が残っているようです。もう少しソースを追ってみないといけないかな。
gitk で文字化けするのも同じ理由のような気がします。

706 :703:2010/07/27(火) 12:59:00
>>705
こちらこそ助かります

ちょっと長文で書いちゃってわかりにくくなっててすいません

Cygwinの話もまざっているのでmsysGit UTF-8で整理すると

・Git Cheetahのファイラーからのコンテキストメニューから立ち上げた場合の話
・"Git Commit Tool"もしくは、"Git GUI"はコミットログやマルチバイトのファイル名の表示コミットも特に問題ない様子
・上記のGit GUIからgitkを起動した場合、
 ・ファイル名は文字化け
 ・diff表示がUTF-8のファイルは文字化けしない(SJISは文字化け)
 ・$HOME/.gtkなどの設定が反映されている様子
・"Git History"からgitkを立ち上げた場合、
 ・ファイル名は文字化け
 ・diff表示がUTF-8のファイルは文字化けする(SJISは文字化けしない)
 ・$HOME/.gtkなどは無視されている気がする?

Cygwinも入れてある環境なため、環境依存の不具合もありそうです。

ファイルの中身がSJISのものは文字化けするのは不便ですが、今回とは別件の話だと思います
(diff表示に異なるエンコーディングが混ざっている場合の問題でもあるし)

今後も長文になりそうだし、githubのissueに行った方がいいかも

707 :デフォルトの名無しさん:2010/07/27(火) 13:49:04
githubのissueトラッカーでやったら?

708 :デフォルトの名無しさん:2010/07/27(火) 13:50:18
>>707
最後まで読まずに書いちゃった。>>706 の最後に書いたあった。


709 :デフォルトの名無しさん:2010/07/27(火) 15:35:57
modern-gitってのもgithubにあるね。
やはりMinGWでの日本語の扱いをどうにかするのが目的みたいで
C++で実装しなおしてるみたい。
どこまで実装できてるかはよく分からないんだけど(個人的にWindows使わないので)

710 :デフォルトの名無しさん:2010/07/27(火) 15:59:07
>>709
mingw前提なので華麗にスルー

711 :デフォルトの名無しさん:2010/07/27(火) 16:01:50
bzr-git/hg-gitで使っているpythonのdulwich使えないのかな?

712 :デフォルトの名無しさん:2010/07/29(木) 22:20:12
バージョン管理システムってどこから入ればいいの?
何を学べばいいの?

713 :デフォルトの名無しさん:2010/07/29(木) 22:34:38
>>712
まずはソースコードの変更履歴を失わない感動から学べばいいと思う
次に、変更者が常に追跡出来ることによる疑心暗鬼の解消、心の平穏を味わえば入門は終わり

714 :デフォルトの名無しさん:2010/07/29(木) 22:41:25
>>712
http://mercurial.selenic.com/wiki/JapaneseTutorial

715 :デフォルトの名無しさん:2010/07/29(木) 23:04:00
>>712
他人と共同作業して足踏みまくるとこから。

716 :デフォルトの名無しさん:2010/07/29(木) 23:07:33
>>712
IBM Rational ClearCase か Microsoft Visual SourceSafe だな

717 :デフォルトの名無しさん:2010/07/29(木) 23:13:18
>>712
RCS

718 :デフォルトの名無しさん:2010/07/29(木) 23:27:07
>>716
あえて最初は地雷踏ませるのか。

719 :デフォルトの名無しさん:2010/07/31(土) 14:21:31
>>712
まずはzipとかでソースを公開しているのにバージョン管理のリポジトリをさらさないソフトの作者を罵倒したり、
HDDが吹き飛びましたので開発中止します、というソフトの開発者をこけ下ろすブログエントリーを書いたり
するところから始めたらいいと思う

何かやりとげたい目標があったとき
(この場合は例えば「バージョン管理を使いこなして他のプログラマーよりも優位性を保ちたい」といったような)
まずは自分がその目標をすでに到達しているかのように振舞ったり想像してい行動することが重要


720 :デフォルトの名無しさん:2010/07/31(土) 14:29:40
>>719
> >>712
> まずはzipとかでソースを公開しているのにバージョン管理のリポジトリをさらさないソフトの作者を罵倒したり、
> HDDが吹き飛びましたので開発中止します、というソフトの開発者をこけ下ろすブログエントリーを書いたり
> するところから始めたらいいと思う
>
具体例が分からんが、forkすればいいだけじゃないの?

721 :デフォルトの名無しさん:2010/07/31(土) 14:46:20
は?

722 :デフォルトの名無しさん:2010/07/31(土) 23:17:42
夏はネタにマジレスだよな(tameiki

723 :デフォルトの名無しさん:2010/07/31(土) 23:52:09
>>712
vadm

724 :デフォルトの名無しさん:2010/08/01(日) 12:47:44
>>720
cvs/svn import
git/hg commit --date

725 :デフォルトの名無しさん:2010/08/02(月) 11:27:47
>>719
×こけ下ろす
○こき下ろす(扱き下ろす)
意味は、「しごいて」落とすことだ。つまり、おまいらが日夜やっていることだな。

726 :デフォルトの名無しさん:2010/08/02(月) 18:29:38
落としてないよageてるよ!!!!!

727 :デフォルトの名無しさん:2010/08/03(火) 19:57:38
マジレスすれば、TortoiseSVNでローカルレポジトリを作って
自分がよく変更するファイルを管理するとこからはじめるといい。

学んでるときに、それとは関係ない文字コードだとかの問題にひっかかったり、
コマンドライン叩くのはなかなか難しいものがある。普段からコマンドラインに
慣れ親しんでる人なら話は別だが。

728 :デフォルトの名無しさん:2010/08/03(火) 20:06:19
TortoiseCVSすらあるのにTortoiseRCSは無いのかな?

729 :デフォルトの名無しさん:2010/08/03(火) 21:56:24
>>728
rcsは分散バージョン管理のカレントパスにレポジトリを作る仕様によって完全に
その役目を後続に明け渡したと思う。

そろそろ休ませてあげてもいいんじゃないかな。

730 :デフォルトの名無しさん:2010/08/03(火) 21:59:10
TortoiseGit

731 :デフォルトの名無しさん:2010/08/03(火) 22:21:12
>>729
でもまだメンテされているみたいだね。
http://git.savannah.gnu.org/cgit/rcs.git/
git?!


732 :デフォルトの名無しさん:2010/08/04(水) 17:48:21
>>727
なぜ分散型でなくTortoiseSVNでローカルレポジトリを作るのか理由を教えてください。

733 :デフォルトの名無しさん:2010/08/04(水) 17:55:48
GitもHgも現状日本語ファイル名の扱いに問題を抱えてるからな

734 :デフォルトの名無しさん:2010/08/04(水) 18:00:02
サーバのセッティングは後回しでいいじゃない

735 :デフォルトの名無しさん:2010/08/04(水) 18:29:06
>>733
SVNは問題無いのですね?

736 :デフォルトの名無しさん:2010/08/04(水) 18:40:33
>>733
ローカルで使う分には関係ないんじゃないの?

737 :デフォルトの名無しさん:2010/08/04(水) 18:43:09
SVNのリポジトリを作ってチェックアウトしてtrunk,branches,tagsを追加するのは初心者向けだとは思えません。

738 :デフォルトの名無しさん:2010/08/04(水) 20:05:15
>>733
但しWindowsに限る
なんじゃなかったっけ?

739 :デフォルトの名無しさん:2010/08/04(水) 20:12:29
>>738
違います。ロケールに限るです。
Unixではja_JP.EUC-JP,ja_JP.UTF-8であれば問題なく動きます。

740 :デフォルトの名無しさん:2010/08/04(水) 20:29:58
ロケールだと語弊があるので、
ファイルシステムのパスがバイト列かUnicodeかの違いと
そのAPI(fopen)の違いです。

174 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)