トップページ⇒tech
1001コメント314KB

Git 2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/09/14(火) 21:38:18
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

◆前スレ
git スレッド
http://hibari.2ch.net/test/read.cgi/linux/1197798039/

◆関連サイト
Git入門
http://www8.atwiki.jp/git_jp/
0153デフォルトの名無しさん2010/11/07(日) 03:31:14
例えばどういうこと？

逆引き的なドキュメントが少ないという話であれば
ProGit一通りよむとかなり解決するが
http://progit.org/book/ja/
0154デフォルトの名無しさん2010/11/07(日) 03:38:18
むしろgit使ってみて今までやりにくかったことが簡単にできてびっくりしたけど
Subversion使っていてこういう機能欲しかったんだ、というのがあったり
TortoiseSVNからコマンドラインに移行したのも理由だと思うが


ただ、>>152がいうのもわからなくはなくて、〇〇はrebaseでできる、といった場合に、
何故○○というコマンドじゃないのか？と思ったり、
もちろん基本的なコマンドは用意しとくから、各個人勝手にaliasしろや、
という一貫したなげやり感もUNIX的にはわからんでもないし、
出来る事多いからコマンドかなり増えるだろうし。

Bazaarは確か標準のaliasもあるしかなりコマンドあったはず。
どっちがいいかという話だな。GUIがメインならコマンド多くても気にならないんだけどね。


0155デフォルトの名無しさん2010/11/07(日) 03:59:41
gitは、もしPro Git（の日本語訳）がなければ、少しでも難しいことは
何もできなかっただろう、という気はする
0156デフォルトの名無しさん2010/11/07(日) 04:25:12
便利そうなんだよなあ。
それはわかってるんだけど、
どうも Mercurial から移行できない。
0157デフォルトの名無しさん2010/11/07(日) 04:25:50
Mercurialってどうなの？
0158デフォルトの名無しさん2010/11/07(日) 05:02:34
Mercurial は分散で高速なんだけど凝ったことしなきゃ svn なんかとそんなに変わらない感覚で使える。
git は便利な分だけ覚えなきゃなんないことがある。ちょっと感じが違うよね。

# Bazaar は Mercurial に近い上ロケールとかしっかり作ってあるけど遅そう。

Mercurial でいいや。とか思ってたんだけど、このスレ見てると、やっぱ git が気になってw
0159デフォルトの名無しさん2010/11/07(日) 05:08:52
ほー。今度使ってみようかな
0160デフォルトの名無しさん2010/11/07(日) 08:42:55
hgは基本機能は限定されているけど、hgに同梱されている拡張のMQを使えばほぼgitと同じことができる。
hgとgitは概念的にはかなり似ているけど、決定的に違うのがブランチの考え方。
hgの名前付きブランチがgitに無い。
0161デフォルトの名無しさん2010/11/07(日) 11:59:47
>>160
名前付きブランチってどういう感じのもの？
0162デフォルトの名無しさん2010/11/07(日) 12:30:21
> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのブランチにリビジョンの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
0163デフォルトの名無しさん2010/11/07(日) 12:35:01
すまん。肝心な所で間違った。

誤）
１つ１つのブランチにリビジョンの名前が埋め込まれている。
正）
１つ１つのリビジョンにブランチの名前が埋め込まれている。

> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのリビジョンにブランチの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
0164デフォルトの名無しさん2010/11/07(日) 12:51:30
>>163
なるほど、なんか分かった。確かにGitはブランチの名前自体には意味を持たないので、
最初使い始めの頃はそこに戸惑った気がする。この変更ってどこから（どのブランチから）
来たんだろ？って思った時によく分からないんだよね。
マージコミットのログメッセージにブランチ名が書かれるから、gitkとかで視覚的に見れば
なんとなく分かるけど、それでもFast-forwardだったりすると完全に統合されちゃうから、
masterでやった作業なんだかtopicでやった作業なんだか、一見分からない。
0165デフォルトの名無しさん2010/11/07(日) 12:55:13
俺も１人で開発する時はmercurialだな。
慣れてるからってのもあるが開発に全く無駄が入らない。
コミットを綺麗に整形したい時はgitを使う。
0166デフォルトの名無しさん2010/11/07(日) 17:25:47
GitExtensionでgit rebase -i 相当のことをするにはどうすればいい？
0167デフォルトの名無しさん2010/11/08(月) 03:02:41
Subversionのときはコミットミスっても気にならなかったが、
gitだと下手に直せるからつい気になるわ

>>164
履歴をフラットにしたくて気軽にrebaseすると、rebase前のブランチなくなって焦るわｗ
仕様上、当たり前なんだが

cherry-pickするか別のブランチ名つけろ、というのはそうなんだけど
0168デフォルトの名無しさん2010/11/08(月) 09:46:43
>>164
そこで git merge --no-ff
0169デフォルトの名無しさん2010/11/08(月) 10:46:33
fast-forward の意味がいまだにわからない‥‥
0170デフォルトの名無しさん2010/11/08(月) 17:11:03
>$ git checkout master
>$ git merge hotfix
>Updating f42c576..3a0874c
>Fast forward
>README | 1 -
>1 files changed, 0 insertions(+), 1 deletions(-)
>このマージ処理で 『Fast forward』 というフレーズが登場したのにお気づきでしょうか。マージ
>先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に
>進めたのです。言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットを
>マージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。マージ対象が分岐し
>ているわけではないからです。この処理のことを 『fast forward』 と言います。
0171デフォルトの名無しさん2010/11/09(火) 00:15:29
>>169
fast forward＝ブランチのポインタをずらすだけ

分岐してなければ、これでいけることが多い


分岐しててfast forwardしたければ、rebaseしてコミットを直線にして分岐なくせばfast forwardできるが、
以前のブランチなくなるから注意。
これ防ぐには別のブランチ名つけておけばよかったはず。


そういえばpush(git svn dcommit)したあとに間違えてgit commit --amendしてしまっていて、
fast forwardなmergeができずあとから気づいてあせったことある。
rebaseだと駄目で、cherry-pickでamendした分を飛ばして解決したが他にいい方法合ったのか
0172デフォルトの名無しさん2010/11/09(火) 02:47:58
分かった気がする
ブランチの方に進んだだけの状態と、
ブランチの方に進んで一方masterの方も進んでいる状態の
2パターンでmasterにマージしてみたら前者だけがfast-forwardって出たわ。
前者は別にマージする必要というか絶対コンフリクトしないから
ただポインタをブランチの先頭だったところにずらしました、ってことだな
0173デフォルトの名無しさん2010/11/10(水) 17:09:04
git checkout の対象がブランチか、ディレクトリか判断つかないとき
git checkout dir/ とやってみたらディレクトリに反応して俺すげー
とおもってマニュアル見たら git checkout -- dir とすりゃよかったのな
0174デフォルトの名無しさん2010/11/11(木) 09:40:29
>>172
fast-forward mergeとそうでないmergeは、gitk --allでマージ前とマージ後を見ながら視覚的に確認するとわかりやすいよ
0175デフォルトの名無しさん2010/11/11(木) 10:28:02
gitk --all やってみたらマージで混乱してた頃の
枝がはちゃめちゃに混線しててワロタ
0176デフォルトの名無しさん2010/11/12(金) 11:44:13
書いてたらgit関係ないことに気づいたけどそのまま投稿するね

githubで公開されてるライブラリがあるのです
で、そのライブラリのバグを直そうと思いました
でも、バグ近辺関連のテストが全然ない上に、この訂正の適用前後で微妙に動作が変わります

・訂正前のメソッド動作はこういう単体テストを満たすものでした（を自作で追加する）
・訂正前と訂正後でこのように動作が変わりますつまりこの訂正コードは正当です
・訂正後のメソッド全体の単体テストです

の3種類のテストが、少なくともpullリクエストでの説得に必要な気がするのです
うまいまとめ方ないでしょうか
訂正後のメソッドについてのテストだけだと、
「この動作は以前のコードではどうだったの？」という情報がなくて困りそうで
0177デフォルトの名無しさん2010/11/12(金) 11:58:45
githubのpullリクエストの現在の挙動は、
ブランチに対してリクエストを出して、その後、そのブランチにコミットを追加すると、pullリクエストも伸びていく。
だから、pullリクエストはブランチ単位で分けた方が良いのでは？
マージするかどうかは、そのリクエスト先が判断すれば良い気がする。
0178デフォルトの名無しさん2010/11/12(金) 12:07:11
ブランチ単位で説得して、ブランチの中のどのコミットを採用するかはまぁすたぁに任せる
だから普通に「○○を改善するブランチ」を作って、
訂正前コードに対するテストをコミットして(a)、
比較対照テストをコミットして(b)、
比較対照テストの部分を極力編集しないように訂正後のコードに対するテストをコミット(c)すればいいのでは
まぁすたぁはおそらく
「コミットすべてを見て納得して、(a)と(c)だけ受け入れ、適当にCHANGELOGを書く」
ということをするはず

…慣れてればな
…慣れてればね
慣れてないと「こんな大きいの無理です入りませんいやっやめてっ」とか返事が返ってくる
0179デフォルトの名無しさん2010/11/12(金) 20:18:51
このへんの作法みたいなのの説明ってあんまりないよね
他者と関わりあっていかなければならないソフトウェアなのにさ
0180デフォルトの名無しさん2010/11/14(日) 09:59:04
パッチはメールの本文にベタで置かないと読まないとかいうプロジェクト管理者もいるし、
いろいろなソフトをひとまとめにできるルールなんて作れない
0181デフォルトの名無しさん2010/11/15(月) 10:33:41
gistが壊れてないか？
"New Gist"でPublic Gistを作ると
無関係のランダムな既存のgistからforkしたみたいになる
Privateだと起こらなかった。昨日から使い始めたんだか元々こうなの？
0182デフォルトの名無しさん2010/11/15(月) 10:52:46
https://github.com/blog/744-today-s-outage
0183デフォルトの名無しさん2010/11/15(月) 13:10:36
700000番から直ったみたい>gist
0184デフォルトの名無しさん2010/11/15(月) 17:16:20
git cvsimportを始めてからもうすぐ20時間。
進行状況の表示もまったくないしいつになったら終わるんだこれは・・・
0185デフォルトの名無しさん2010/11/15(月) 19:26:19
俺も以前cvsimportしたことあるけど、めっちゃ時間かかった上に
異常終了してたような気がするな。。。
ローカルにあるならまだしも、リモートではもうやりたくないと思った。
0186デフォルトの名無しさん2010/11/16(火) 02:54:10
git svnも小さいプロジェクトなのに最初のcloneに小一日かかったわｗ
0187デフォルトの名無しさん2010/11/16(火) 03:21:07
>>186
githubとかにもありそうな著名なプロジェクトなら、こういう手もある
git-svnを途中から始める - unpushの日記
http://d.hatena.ne.jp/unpush/20090826/1251281749
0188デフォルトの名無しさん2010/11/17(水) 10:51:13
cherrypickのたびに1文字1文字コミット名を入力するのが大変なのですが，
簡単に入力できる仕組みはあるのでしょうか？
解説等を読んでも引数にSHAの頭数桁を指定しているだけで・・
0189デフォルトの名無しさん2010/11/17(水) 11:44:01
>>188
ハッシュの意味をよーく考えよう
0190デフォルトの名無しさん2010/11/17(水) 15:50:39
>>188
ターミナルからコピペするの楽だから大変と思ったことないな。
master~5みたいな記法使ったらどうだろ？
0191デフォルトの名無しさん2010/11/17(水) 15:55:33
ああそうか、現在表示してるコミットのハッシュ値をマウス等でコピーできない環境なのか
それは使用環境が糞だというしかないな
0192デフォルトの名無しさん2010/11/17(水) 16:37:39
マウスなくてもscreenでコピペしてる。
zshやbashならハッシュ一覧表示する補完関数書けばいけるかも。
0193デフォルトの名無しさん2010/11/17(水) 17:09:01
最初の2文字ぐらい打てばほぼ一発補完できるeshellというかEmacs最強
0194デフォルトの名無しさん2010/11/17(水) 18:37:54
環境はMacです．
Terminalなのでコピペできるんですが，
どうしてもUNIXの保管になれてると少しだけ入力してTabで保管してくれないのかなー
等と欲がでてしまって・・（マウスも使っていないのでタッチパッドだとやりづらいorz）

Git自体にそういった保管機能はないということですね・・
git log --oneline で地道に拾います・・
0195デフォルトの名無しさん2010/11/17(水) 20:17:47
>>194
マウス使わないなら尚更screenがいいよ
0196デフォルトの名無しさん2010/11/18(木) 03:08:53
てかSHA1を直打ちしなくていいように refs/heads があるんだと思うんだが、、、
0197デフォルトの名無しさん2010/11/18(木) 06:20:40
>>196
こんなのあったんだ。

これってローカルのブランチ名と違うの？
ローカルのブランチ名に近い範囲だったら >>190の記法でいけるんじゃないの
0198デフォルトの名無しさん2010/11/18(木) 08:00:45
>>197
ローカルブランチと同じだよ。
refs/heads/〜とかrefs/remotes/〜とかはそこまでを省略して指定することができる。
ちなみに.git/HOGEHOGEとかを勝手に作ってもgit log HOGEHOGEとか出来ちゃう。
0199デフォルトの名無しさん2010/11/18(木) 11:08:08
へぇー、ORIG_HEADって定数が使えるのも .git/ORIG_HEAD の中を見てたってことなのか。
0200デフォルトの名無しさん2010/11/19(金) 11:17:35
ということは.gitをgitで管理すればブランチの変異もバージョン管理できるわけか
0201デフォルトの名無しさん2010/11/19(金) 11:23:35
>>179
githubについてはドキュメント足りないよね
pullリクエストを送るボタンの押し方なんて本気でどうでもいい

pullリクエストとして送る予定のコミットのいい書き方とか
pullリクエストの受け入れ方とか吟味の仕方とか説明がない
0202デフォルトの名無しさん2010/11/22(月) 02:59:59
>>194
一意に決まる場合はハッシュの頭数文字だけの入力で適切に処理される。
0203デフォルトの名無しさん2010/11/22(月) 03:19:55
今試してみたら、最低でも４文字は必要ぽい
0204デフォルトの名無しさん2010/11/27(土) 00:44:29
git add .
git commit -m "git boy"

としてindexに追加、コミットした後で余計なファイルをコミットしていたと気づいたので
ファイルはそのままにコミット前に戻したいと考えました。
（実際にはCygwinでファイルのモードを変更したつもりがないのに、
core.filemode = falseにし忘れていて意図せずファイルのモードが変更されまでがaddしてしまったのです）

　git reset --soft HEAD^

のように編集したファイルはそのままにしてコミットを取り消すことが出来ますが、

　git add .

が取り消すことができませんでした。

そこで、
　git add -r --cached .
としたのですが、git addしたもの以外も全て取り除いてしまうようです。

git addしたもののみ的確に取り消すにはどうしたらよいでしょうか？

0205デフォルトの名無しさん2010/11/27(土) 01:11:11
git reset head で、いいんじゃないかな
0206デフォルトの名無しさん2010/11/27(土) 01:25:12
>>205
あれ？それでいいんだ
いけました

ありがとうございました！
0207デフォルトの名無しさん2010/11/27(土) 13:17:58
複数のサブプロジェクトをひとつのリポジトリで管理するときの指針やコツみたいなのがあったら教えてください。
0208デフォルトの名無しさん2010/11/27(土) 13:35:42
>>207
gitosis
0209デフォルトの名無しさん2010/11/27(土) 15:06:43
>>208
そういう意味じゃないんじゃない？
submodule とか？　でもあんま使い勝手良くないんだよねぇ。
0210デフォルトの名無しさん2010/11/29(月) 02:29:52
Gitならこの人に聞け！
というぐらいのGit使いが身近にいればな・・・
名古屋近辺にいないかな？
0211デフォルトの名無しさん2010/11/29(月) 10:04:51
>>210
ttp://atnd.org/events/7556
のような集まりに参加すればいいんじゃないか。
ひとまず git 名古屋 でググれ。
0212デフォルトの名無しさん2010/11/29(月) 12:04:24
A：共用リポジトリ（自動的にDにプッシュ）
B:個人修正用リポジトリ（自動的にCにプッシュ）
C:修正＆テスター確認用ディレクトリ
D：本番適用待ちディレクトリ
　
D ---- RepoA (master)　　　RepoB (master) ---- C
　　　　　　　｜＿＿＿＿＿＿＿＿＿｜
　　　　　　　　　　　　　T
　　　　　　　　　　　　Local

現在上記のような形でローカルでブランチを切り替えて運用しているのですが
このような形だと当然だとは思いますが、歴史がおかしいとしょっちゅう怒られ、
サクサクと作業をすすめることができません・・
例えばRepoBには修正過程のゴミコミットがたまり続けるので
修正が完了してRepoA用のブランチにマージする際、
その修正をrebase -iでまとめてからRepoAブランチからcherry-pickしているのですが、
これをやってしまうと別の作業でRepoBにプッシュすると怒られてしまうという状態です

もっと上手な運用方法はないでしょうか・・
0213デフォルトの名無しさん2010/11/29(月) 12:47:15
リモートのリポジトリって1個じゃだめなの？
0214デフォルトの名無しさん2010/11/29(月) 13:11:34
＞RepoBにプッシュすると怒られてしまう

RepoAに切り替える
(RepoBのものを)整形したコミットをpush

RepoBに切り替える
ゴミコミットを取り消すためreset --hard
RepoAからcherry-pick
push

もしかしてresetした？それなら怒られて当然だ
普通に1つの共用リポジトリで
masterとstableブランチ作って運用するのじゃ駄目なの？
0215デフォルトの名無しさん2010/11/29(月) 14:20:47
RepoBをなぜ使用しているかというと
開発に参加している各人がRepoBを持っていたほうが
お互いの修正がバッティングしにくいと考えたためです

RepoAに各人のブランチを作る方法も考えたのですが
開発に参加する人数が増えるとそのたびにブランチを切らないといけないのかなーと・・
どのみち各人のRepoBを作成しているのでそのほうがめんどくさいかもしれない・・ですね・・・
0216デフォルトの名無しさん2010/11/29(月) 14:29:14
開発者各自はどうせ自前の作業用リポジトリを持つんだろうから、
・各自そこから中央にpush
・メンテナが各自からpull
のどっちかをやって、その都度当事者が責任を持ってコンフリクトを解消する。

お互いの修正がバッティングするのは分散して作業していれば必ず起こりうることで、
どこかでそれを解消したらそれ（マージされた状態）を保持しつづけるようにする
姿勢が必要。rebaseやcherry-pickしたら、された側のブランチは捨てるつもりで
やる必要がある。
0217デフォルトの名無しさん2010/11/29(月) 22:37:21
>>215
個人用のリポジトリRepoBを外にも持つ理由がわからない。
冗長性を保つためだけの存在なら、ローカルから直接本番のリポジトリRepoAにプッシュせず、RepoBでブランチ切ってmasterへのマージ時にRepoAへプッシュするようHookさせたらいいんじゃないか？
0218デフォルトの名無しさん2010/11/30(火) 03:28:14
>>210
とりあえず@bleisさんという人が詳しいみたいです。
どんな人か知りませんが。
0219デフォルトの名無しさん2010/11/30(火) 17:53:39
一月前のエントリだが。
http://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html
0220デフォルトの名無しさん2010/12/01(水) 08:41:10
マスタがsvnだとどうしてもrebase主義にならざるおえない。…追えない!?
0221デフォルトの名無しさん2010/12/01(水) 08:50:24
はいはいワロスワロス
0222デフォルトの名無しさん2010/12/01(水) 16:16:08
>>220
ﾅｶｰﾏ
git svn使うときはrebaseしまくりだわ

でも最近面倒なのでsvnにあるまじきリモートブランチ切りまくり
0223デフォルトの名無しさん2010/12/01(水) 17:02:16
svnの人が居ると最終的にsvnにrebaseしないといけないのって泣けてくるよね。
svn側でブランチとか作ってもけっきょくただのコピーだし、gitから見れば別モノなわけで。
svnのDBにGit互換の世界が作れればいいんだけどねぇ。propsとかでどうにかならないかな。
0224デフォルトの名無しさん2010/12/01(水) 22:46:16
無理にgit-svnで連携させようと思うのがいけないのだと悟った
.svnと.gitが共存するスペースを作れば種々の問題が解決した
0225デフォルトの名無しさん2010/12/01(水) 22:58:09
それって削除ファイルがあったときにめんどくね？
0226デフォルトの名無しさん2010/12/01(水) 23:01:32
コンフリクトした時も痛いことになりそうだ
0227デフォルトの名無しさん2010/12/01(水) 23:34:57
svnからupdateする時はその都度branchを切るな
大した手間じゃないし
0228デフォルトの名無しさん2010/12/02(木) 00:02:45
Macのデザイナーさんがよろこびそうなgitクライアントきてた
Tower - The most powerful Git client for Mac
http://www.git-tower.com/

0229デフォルトの名無しさん2010/12/02(木) 00:25:06
>>228
やたらオサレだな。gitもマカーにかかればこうなるのかｗ
0230デフォルトの名無しさん2010/12/02(木) 00:52:12
まだ使ってないから見た目でしか判断できないけどこりゃ…すごい…
毎回思うんだがgoogleの機能紹介アニメ作る人とか、レタッチツールやDAWのデベロッパには劣等感を感じてしまう。
飛車と角が合体したような連中ってのはいるもんなんだな。
0231デフォルトの名無しさん2010/12/02(木) 01:03:46
こりゃいいなｗ
0232デフォルトの名無しさん2010/12/02(木) 02:33:05
>>228
http://www.git-tower.com/img/screenshots/history_recent_big.jpg
うける
0233デフォルトの名無しさん2010/12/02(木) 11:02:16
git mergetoolでP4Merge使ってるんだけどマージした後にgit statusすると
modifiedとなる場合とならずにNot currently on branchとだけ表示されてcontinueできない
0234デフォルトの名無しさん2010/12/02(木) 23:30:20
>>230
Queen最強、と思ってたらKnightによくヤられる
0235デフォルトの名無しさん2010/12/02(木) 23:34:35
紹介しておいてなんだけどMacじゃないから試せない・・・
試した人感想くれ


gitじゃないけどBzrExplorerはいい線いっていると思うけどね。
次に何すればいいかってのが分かる。

バージョン管理ソフトばかりの話しではないけど慣れないときに困るのが、なにすればいいねん？ってことだからな
0236デフォルトの名無しさん2010/12/03(金) 00:53:57
GitX風だな。
0237デフォルトの名無しさん2010/12/03(金) 01:22:15
これいいとおもったらコミットメッセージ日本語うてないなｗ
0238デフォルトの名無しさん2010/12/03(金) 08:59:01
git-svnには完全には対応してないだと！？まーしょーがないか。
が、俺の感想。
0239デフォルトの名無しさん2010/12/07(火) 09:11:31
>>4
これが日本語ファイル名を扱う唯一の手段？
みんな日本語ファイル名をどうやって扱ってるのかな？
コードは日本語ファイル名はないと思うけど、ドキュメントとか普通日本語でしょ。
ドキュメントはバージョン管理しないの？
0240デフォルトの名無しさん2010/12/07(火) 09:27:13
追記
クライアントがSJISのWindowsマシンで開発して、リポジトリをLinuxにおいているような場合
0241デフォルトの名無しさん2010/12/07(火) 09:38:48
http://code.google.com/p/msysgit/issues/detail?id=80
0242デフォルトの名無しさん2010/12/07(火) 09:42:31
ヨハネスやる気無さ杉だろ
0243デフォルトの名無しさん2010/12/07(火) 11:20:19
>>239
cygwin使えば使えるらしい
0244デフォルトの名無しさん2010/12/07(火) 12:11:54
SVNはちゃんと日本語ファイル名扱える(Linux/Windows間でも問題なし)のだけど
あれはどうやって解決してるんだろう
0245デフォルトの名無しさん2010/12/07(火) 12:18:38
パスとログはUTF-8と決まっていてクライアントが自動的に変換してる
0246デフォルトの名無しさん2010/12/07(火) 12:19:20
なんでGitだとそんな簡単なことが出来ないんだろう
0247デフォルトの名無しさん2010/12/07(火) 12:20:37
まあ少なくとも
「UTF-8決め打ちでプログラムがファイルパスを自動変換する」
という台詞を見て何も感じない人向けのソフトウェアではない
0248デフォルトの名無しさん2010/12/07(火) 12:34:12
>>245
違うよ。LANGで勝手に変換しちゃうんだよ。大きなお世話、勘違いだけど。
それが簡単だと思っているんなら、SubversionかBazaar使って満足していれば？
0249デフォルトの名無しさん2010/12/07(火) 12:49:46
エンコーディングを自動判定してるなんて一言も言ってないのに
特定プラットフォーム限定のLANGとか持ち出して勘違いとか言われても
0250デフォルトの名無しさん2010/12/07(火) 12:55:49
>>249
SubversionとBazaarがLANGで勝手に判定する勘違いアプリってこと
0251デフォルトの名無しさん2010/12/07(火) 13:09:26
日本人でさえ混乱してるのに
ヨハネスが上手く作りこめる訳がないな
0252デフォルトの名無しさん2010/12/07(火) 13:23:09
あらゆる意味で「日本人しかうまく作れない」と思う
おまえ日本人か、みたいな日本語べったりの外国人エンジニアなら可能かもしれんがまあ稀だな

俺らがやるヨーロッパ系言語のISO-8859-Xの扱いがへにょいのと同じ理屈
■ このスレッドは過去ログ倉庫に格納されています