984コメント325KB

git スレッド

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

0001login:Penguin

2007/12/16(日) 18:40:39ID:GslAi8rs

ソースコード管理を行うバージョン管理システム、git について語ろう。

あの、リーナス・トーバルズだって、バージョン管理を始めたんだ。
http://www.kernel.org/pub/software/scm/git/

git チュートリアル (バージョン 1.5.1 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html

0693login:Penguin

2010/03/11(木) 05:05:22ID:vWTSpXf4

俺は気づかなかった。見た瞬間とりあえずくだ質問行けよとか思った。

0694login:Penguin

2010/03/11(木) 07:17:44ID:a4pU/TF4

>>686
>git clone 'http://～'だと反応したんだと思います。
だから反応ってどういうことだよ池沼が

0695login:Penguin

2010/03/12(金) 00:35:01ID:g58g7Khc

まあ落ち着け。
とりあえず俺はgitどころか
カーネルのアップグレードに失敗したらしく
かなり焦ってる
バックアップの必要性は必要になってから気づくんだ

0696login:Penguin

2010/03/14(日) 23:02:16ID:74SKWdA2

コミットの指定で使う ~ と ^ の違いがよく分からないんだけど、
例えば、HEAD~2 とか HEAD^2ってどう使い分けたらいいの？

0697login:Penguin

2010/03/15(月) 00:13:16ID:9vDzc51S

縦軸と横軸だ

0698login:Penguin

2010/03/15(月) 00:17:27ID:9vDzc51S

c~3-c~2-c1~-c(HEAD)
　　　　　　c^2 」
　　　　　　c^3 」

c~3-c~2-c1^-c(HEAD)
　　　　　　c^2 」
　　　　　　c^3 」

0699login:Penguin

2010/03/15(月) 00:18:53ID:9vDzc51S

^複数の親と、~複数の世代の違い

0700login:Penguin

2010/03/15(月) 00:20:25ID:vdbEsin0

その２つは異なるものだよ
~nはn個前の親を表していて
^nは1つ上のレベルのn個目の親を表す
　　D-E
　 /　　　\
A-B-C-F
FがHEADの時にAはHEAD~3
CかEがHEAD^1、HEAD^2。

0701login:Penguin

2010/03/15(月) 00:58:04ID:INJko3Py

ありがとうございます。やっと分かりました。
^はマージによってコミットに複数の親がある時、それぞれの親を指定できるんですね。
すっきりしました！

0702login:Penguin

2010/03/15(月) 03:38:25ID:5FqVvyVi

すっきりしない

0703login:Penguin

2010/03/16(火) 09:03:16ID:5gE8Vm9w

subversion からcloneしたリポジトリで git branch -r　すると@12とか
複数のバージョン？見たいなのが出てくるんですが、これはなんですか？

0704login:Penguin

2010/03/16(火) 18:59:10ID:I38d2Qfd

gitは基本的に戻ることはないんだねぇ、
恥ずかしい失敗したらコマンド使ってコミット無かったことにするけど

0705login:Penguin

2010/03/16(火) 19:22:14ID:UUVEpT2o

基本的に戻ることがあるようにしてるVCSなんてあるの？

0706login:Penguin

2010/03/17(水) 21:14:49ID:ZS5QfrTO

git reset でいくらでも戻れるぜ。ただ、それよりも
1. 作業用ブランチでは気にせず commit/revertしまくる
2. 作業終わったら作業用ブランチの根元から新しくブランチを切る
3. cherry-pick とかで綺麗な履歴を合成
4. 作業用と新ブランチのdiffに差がないことを確認
5. 作業用ブランチはまるごとさようなら
がオススメ。1commit に複数の仕事を含めないようにしないと後で
カオスになるけど。

0707login:Penguin

2010/03/18(木) 00:36:24ID:dr1HU4dM

>>706
お前は俺かｗ
そんな神経質なことやってるのは俺ぐらいなもんだろうと思ってたぜ。
ただ、履歴が綺麗だと気分良いけど、仕事ではそれなりで我慢するようにしようと心がけてる。

あとそのやり方やってると、diffで何も出ないんだからgit branch -D でさよならで
良いはずなんだけど、どうも念のために残しておきたくなっちゃうんだよな。。。
だからtopic_bk1 topic_bk2 ... とかいう感じで、ゴミブランチがたくさん残ってしまう。

0708login:Penguin

2010/03/18(木) 00:48:06ID:wZ6/zNxh

それでいいんじゃね？　増井俊之のいう富豪的プログラミングの一例として

テキストデータなんてどうがんばってもHDD1台分も書き溜めることはできないんだから
いくらでも残しておけばいいんだと思うよ

0709login:Penguin

2010/03/18(木) 01:28:19ID:dr1HU4dM

でもあれだぜ、git branchが一画面分超えちゃうようになるとちょっと考えちゃうぜ。
デフォで git branch | grep hogehoge しないと使ってられない。
ってまあ、そうなる前に整理しろって話なんだけどね。。。

手動でgcした時だけ消える（消えなくてもいいけど）普通にはリストに出てこないtrashes的な属性が
ブランチに付けられたらいいなと思った。けどgit-branchはスクリプトじゃなくてC実装だったので寝る。

0710login:Penguin

2010/03/18(木) 02:50:25ID:6BBqQXR0

あー、なるほど、作業用ブランチでrevert使ってなかったわ

0711login:Penguin

2010/03/18(木) 23:14:55ID:dr1HU4dM

1.7はこんなん変わってるから注意、みたいなの教えて欲しい

0712login:Penguin

2010/03/19(金) 11:41:12ID:r52T5pgD

git tag は-lでタグ指定して見られるのに、git branchは一覧しか見られないのはどうしてなぜなんだぜ

0713login:Penguin

2010/03/19(金) 19:37:38ID:NIuQLQlK

>>712
tagは、大抵付けっぱなしだけど、branchはmerge済みになれば(俺は)消しちゃうから
選ばなくても、そんなに沢山出てこないんじゃないかな？

0714login:Penguin

2010/03/19(金) 20:23:13ID:sUcT09Pz

>>709
ゴミブランチが多すぎてうざくなったら、clone して
別リポジトリでとっておけばいいんじゃね？
また必要になったら pull すりゃいいだろうし。

0715login:Penguin

2010/03/19(金) 20:35:42ID:sUcT09Pz

ちなみに >>706 の 3 は commit が多い場合 cherry-pick じゃなく
て format-patch でファイルに落としてから選別、 git am で一気
に進めると楽。ただし、commit log の1行目に適切なサマリを書い
てないと選別作業がカオスにw

0716login:Penguin

2010/03/19(金) 20:55:59ID:sUcT09Pz

あと応用として「なんか2種類のトピックに分割したほうがよくね？」
って状態になったときに、根元のcommitが beef だったとして
1. git format-patch beef で patch ファイル化
2. git checkout -b topicA beef で topicA を作成
3. topicA に必要な patch だけあてていく
4. git checkout -b topicB beef で topicB を作成
5. 残りの patch をあてる
6. git merge topicA で一旦topicBにマージ
7. git diff でもとの作業ブランチと違いがないことを確認
8. git reset HEAD^ --hard でマージ前のtopicBに戻す
9. 作業用ブランチはまるごとさようなら
とかでサクッと分割できる。

0717login:Penguin

2010/03/19(金) 21:01:59ID:sUcT09Pz

ついでにもういっこ。
この手の作業するのに gitk --all は欠かせない。各ブランチHEAD、
ブランチ間のつながり等が一目瞭然なのでイメージをつかみやすい。

0718login:Penguin

2010/03/19(金) 21:55:21ID:sUcT09Pz

>>711
1.7系は俺もつかってないんだけど Relnotes-1.7.0.txt の Notes
on behaviour change をざっくり要約。

* "git push" でpushするブランチがリモート側でチェックアウト
中だったら失敗するようになった。似たような状況だとgit
push <あっち> :ゴミブランチで消すときも弾かれる。

* "git send-email" があんまり深いスレッドを作らなくなった。
これからはカバーレター以外はカバーレターのリプライになりまっ
せ。(設定のデフォルト値が変わっただけ)

* "git status" の実体が "git commit --dry-run" じゃなくなっ
たぜ。今までそれを利用して git status に引数つけて実行して
なければ(普通しないと思う)関係ない。

* "git diff --exit-code -b" ってやったときに diff が出ないの
に exit code が non zero になる場合があったんで、いい具合
に修正しときました。

* External diff と textconv helper が shell で実行されるよう
になるよ。必要ならコマンドラインパラメータ付きで呼び出せる
ようになったぜ。そのかわり外部コマンドのパスに空白が入って
たりする環境は注意。

* "git repack"とかの --max-pack-size オプションが MiB 単位固
定だったけど、byte単位になった。必要なら数字の後ろに k と
か m とか g とかつけてね。

ということらしい。

0719login:Penguin

2010/03/20(土) 01:01:58ID:250FD1S2

>>718
なるほど。すません、英語読むの面倒くさがって。
git1.7は一部後方互換性なし、って見出しでよく言われてるけど、普通に使ってるぶんには
まったく問題なさそうだね。チェックアウト中のブランチにpushしたらデフォで拒否ってのは
安全でとても良いと思う。

>>714
なるほど、そうしてみるわ。ゴミ置き場リポジトリね。最近cloneはハードリンクがデフォになったようなので
そこは注意だけれども、、、

>>717
そうそう、gitk以上に見やすいのは知らない。つってもマージ激しくない時はshow-branchでどうにかなるけど。

>>716
それって最終的にマージして終了？　まっすぐにして残そうとはしないの？

0720login:Penguin

2010/03/20(土) 01:24:01ID:Y/nTXIhi

GUIならgitkかqgitかな、と思ってる

0721login:Penguin

2010/03/20(土) 02:00:55ID:VyCYaEo0

>>719
> >>716
> それって最終的にマージして終了？　まっすぐにして残そうとはしないの？
おっと、topicA, B ともに、まだ作業中のイメージでした。
作業が完了してるなら統合用ブランチにマージして終了ですな。

0722login:Penguin

2010/03/20(土) 04:50:50ID:lzllMVc3

http://sourceforge.net/dbimage.php?id=72597

0723login:Penguin

2010/03/20(土) 22:08:34ID:8SKMhpSs

ずうううううううっと思ってたんだけど、コミットログ書くときに今回どこを変更したかってふつう覚えてなくね
コミットログに書いておくべきであるような変更をぽろっと書き損ねるとかありそうでヤじゃね
それとも忘れないような小さなカタマリで鬱陶しいほど細かく作業単位でコミットするもんなの？
それともみんなコミットログ書くときには別窓で git diff とかの結果眺めつつ書いてるの？

0724login:Penguin

2010/03/20(土) 23:00:31ID:CNETOYMb

>>723
＞コミットログ書くときに今回どこを変更したかってふつう覚えてなくね
git commit -v 使うといいよ。
どこを変更したじゃなくて、なんで変更したのかを書くといいよ。
git diff使えば変更点なんかすぐ分かるんだから。

＞小さなカタマリで鬱陶しいほど細かく作業単位でコミットするもんなの？
鬱陶しいかはしらんけど、俺は結構細かくつけてるけど。
一気に変更した後、git add -p使ってコミット自体は細かくしてる。
この時に、意味的に1種類のコミットにするようにして、
すぐgit commitしちゃうから-vオプションつけなくても、
コミット内容は頭に入ってるかな。

0725login:Penguin

2010/03/21(日) 00:21:34ID:EU6VkwB8

>>723
何か目的があってソースいじってるんだから、その目的を書けばいいんじゃないかね。
逆に言うとどんだけデカい差分になってもいいから、別の目的の差分は入れるべきじゃないと思う。
例えば、機能追加なのにちゃっかりバグフィックスも混ざってるとか。

0726login:Penguin

2010/03/21(日) 09:08:50ID:GHhv3uqI

>>723
gitx ではとりあえずコミットログを書きながら
コミットするファイルの一覧から diff 表示させられるから
忘れてても全然 OK

0727login:Penguin

2010/03/25(木) 08:29:22ID:ACJlY4U7

muzu-

0728login:Penguin

2010/04/01(木) 15:28:34ID:M9uKaIit

Windowsのcygwinのgit使ってるんですが、日本語ファイル名が

# "\343\202\265\343\203\263\343\203\227\343\203\253\343\203\225\343\202\243\343\203\253\343\202\277/"

みたいに数値で表示されるのってなんとかならないものなんでしょうか？
cygwin 1.7なんでUTF-8には対応しているはずなんですが。

0729login:Penguin

2010/04/01(木) 15:29:18ID:M9uKaIit

数値でっていうかバイナリなのか。gitはファイル名をバイナリで扱うんだっけ・・・

0730728

2010/04/01(木) 15:41:21ID:M9uKaIit

gitで日本語ファイル名を無理やり通した - きみのハートを8ビットキャスト
http://d.hatena.ne.jp/takkaw/20080831/p2

こういうのって公式に取り込んでもらう方法ってないもんでしょうか？

0731login:Penguin

2010/04/01(木) 15:45:28ID:8lE6TdJZ

>>729
core.quotepath = false
でいけます。

0732login:Penguin

2010/04/01(木) 16:38:48ID:ivXW99qP

どこかに覗いたら勉強になるようなＯＳＳのＧｉｔレポジトリないでしょうかね？

0733login:Penguin

2010/04/01(木) 22:37:08ID:fogg5tiY

gitだと、公開リポジトリは綺麗な歴史になるようにしてる
はずだけど、どういう勉強がしたいの? 自分で実験してみる
以上に勉強にはならないとおもうけど。

cloneしてから、一個一個コマンドを試していけば
いいんじゃないの?なんかダメなの?

0734728

2010/04/02(金) 03:19:32ID:mth9LXwF

>>731
ｲｹﾀ━（ﾟ∀ﾟ）━ !!

$git config --global core.quotepath false

でいけました。

上記でUTF-8で入れたマルチバイトファイル名は文字化けしてないみたいなんですが、
gitkやgitguiだとコミットログは問題ないようなのですが、ファイル名は化けて、操作できないですね・・・

$ git config --global gui.encoding utf-8

している状態なんですが、これはどうにもならないもんなのでしょうか？

cygwin 1.7.1、 git 1.6.6.1です

0735login:Penguin

2010/04/04(日) 12:24:16ID:N7boF9sc

>>732
ｽﾚ違い

0736login:Penguin

2010/04/11(日) 23:37:35ID:gnsZLsDv

document.createElementで作ったinputをｊQueryで追加したんですが、
そのInputの入力Boxで文字列が選択できません。

これはなぜ？

0737login:Penguin

2010/04/12(月) 01:08:08ID:zlVRCvUq

どこの誤爆だ。

0738login:Penguin

2010/04/12(月) 05:36:23ID:B6m3dSPJ

こんな所に・・・・
誤爆しました。失敬。

0739login:Penguin

2010/04/12(月) 08:45:24ID:i6AEo9WC

こんなところとは失礼だな君は

0740login:Penguin

2010/04/12(月) 09:35:28ID:TaBB+zUC

まあまあ、こんなところというのは良い意味で言ったんだよな、坊主

0741login:Penguin

2010/04/15(木) 01:17:11ID:GwN4l2eh

ついでだからgitについてもひとこと書いてけ、坊主

0742login:Penguin

2010/04/15(木) 15:39:46ID:VoGIIRW/

webdav経由の速度がsvn(mod_dav_svn)に負けるんだけど。
どこが早いだよ。ボケが。

0743login:Penguin

2010/04/15(木) 15:40:06ID:VoGIIRW/

とと間違えた糞がだった。gitだけに。

0744login:Penguin

2010/04/15(木) 16:15:54ID:/XEu1xEv

webdav経由なんて使ったことないな。速度って何の速度？　クローンじゃないよね？

0745login:Penguin

2010/04/16(金) 08:09:07ID:UzWc4Tj9

webdav(笑)

0746login:Penguin

2010/04/17(土) 10:38:01ID:yU9e03Tm

>>741
ぎったんぎったんにしてやんよ

0747login:Penguin

2010/04/19(月) 12:01:21ID:9Dj8CBQk

>>744
クローンだよ。
初回はやっぱりクローンだし。
LLのコード管理するならいいけど
中間コード生成する類のコードだと余計ファイルを一掃したくなるので
中央からクローンする頻度が上がる、クローンが遅いのは痛い。

零細企業の事情は知らんけど、そこそこの企業ならポート制限をかけてて
git用に別ポート開けろとかいやがられるので80ポートは開いてるからwebdav

0748login:Penguin

2010/04/19(月) 12:24:28ID:T4uQ6+sS

>>747
だまってsvn使えばいいじゃない
gitのクローンって、リポジトリのクローンだよ？
速度を比べるのがおかしい

0749login:Penguin

2010/04/19(月) 12:55:20ID:4DqhZF3F

>>748
だな、速度を比べるのならsvnではr1からHEADまで全履歴を取得させて計測すべき。

0750login:Penguin

2010/04/19(月) 15:21:58ID:9Dj8CBQk

>>748
たしかにsvn使う方がいいですね。そうします。

中央リポジトリだけsvnにしてもいいんだけど
それだとブランチ毎にcloneしないといけないっていうのが使いにくい。

Linusさんが作ったわけだから、中間コードを生成するようなものにも
利用してるはずで、多分私の運用方法がまずいと思うんだけど。
git系の解説書見てもよく分からん。

0751login:Penguin

2010/04/19(月) 16:41:09ID:4DqhZF3F

>>747
＞中間コード生成する類のコードだと余計ファイルを一掃したくなるので
＞中央からクローンする頻度が上がる、クローンが遅いのは痛い。
中間コードの生成とクローンの頻度に何の関係があるの？ ignoreとかmakeとか使えないの？
てかクローン（全履歴取得）は最初だけでその後はフェッチ。中央扱いの場所へのコミット頻度が
高ければ、必然的にフェッチする頻度も増すだろうが。

社外とクローズドなソースコードのやりとりするなら会社責任者の認証を受けるべきだし、
そんならちゃんとした手順踏んで相手方とトンネル掘るなりしてsshでやるべきじゃないかと思う。

0752login:Penguin

2010/04/19(月) 22:26:52ID:9lqpgC5I

件の中間生成物を掃除するために、リポジトリまるごと"rm -rf *"で闇に葬ってから
"git clone"してたりするんでないかと。

0753login:Penguin

2010/04/20(火) 00:11:21ID:dxBJHbyQ

うわー

0754login:Penguin

2010/04/20(火) 04:50:52ID:pVtIppVL

普通中間生成物削除する何らかの手段用意するよなあ。
Makefileのcleanターゲットとかさー

0755login:Penguin

2010/04/20(火) 08:39:49ID:1DvR0uQW

んだよそんな低レベルうんこ野郎が、糞だのボゲだのってDISってたのかよ。

0756login:Penguin

2010/04/20(火) 09:29:20ID:4QSw7roF

rm -rf * して git checkout . はたまにやるな
早いし

0757login:Penguin

2010/04/20(火) 10:51:57ID:wr/OBch+

"git clean -dfx"とか使わずにcloneし直して遅い遅い言ってる訳か。

0758login:Penguin

2010/04/20(火) 22:18:12ID:3xiD65pL

>>750
ブランチごとにcloneって意味がわからん
git-svnは普通にSubversionのブランチも追いかけられるぞ？

0759login:Penguin

2010/04/21(水) 08:24:48ID:yetyJ5AV

>>747
UNIX系の環境だったら .gitをコード生成するディレクトリの外に
置いてsymlink貼って使うとか、symlinkが使えない環境だったら
webdavサーバからclone --mirrorした(ローカルの)リポジトリから
git clone -s して使うとか、いろいろ回避策はあるでしょう。

0760login:Penguin

2010/04/22(木) 12:54:59ID:hPfzumYq

git clean知らなかった。便利だ。

0761login:Penguin

2010/04/22(木) 13:32:46ID:93pJE4US

1週間くらい前からライブラリはわりとできた気がするのだがGitHubで公開する勇気が出ない
めちゃくちゃ緊張して手が震えて駄目だ

公開することにした理由って何？

0762login:Penguin

2010/04/22(木) 13:40:24ID:2lkoAWrr

>>761
だいじょうぶ、反響が皆無で逆に落ち込むから。
よっぽどインパクトのあるものかライフチェンジングなもの、もしくは宣伝しまくって煽ったりしない限り、
オープンソースソフトウェアの影響は徐々にくるものだから、気楽にやったほうがいいよ。
で、なにつくったの？

0763login:Penguin

2010/04/22(木) 14:00:26ID:I4eCvKff

>>761
アドバイス求めたら結構くれるよ

0764login:Penguin

2010/04/23(金) 00:44:22ID:S4Z1KuPQ

バイナリの場合は公開時の品質で悩むのもありだが
ソースつきなら
「俺はここまでやって方向示したのであとは凄い人が続きおね」
という思考で世間様にブン投げてOK

放っておけば誰かが使ったり誰かが紹介したり
もっといいものが出て忘れ去られたり
フォロアーどころか類似品すら出ずにカテゴリごと忘れられたりする

0765login:Penguin

2010/04/23(金) 01:01:53ID:AfgDmnjX

きっと世の中には、とんでもなく使いやすくて斬新なアイデアかつ生産性の高い
ソフトウエア（の前身）たちが今日も日の目を見ないままひっそりとどこかにいるんだろうなあ
そういう革新的なソフトたち発掘するネット界の冒険者っていうのもおもしろそうだなあ

という電波をいましがた受信した

0766login:Penguin

2010/04/25(日) 21:13:36ID:T3Ea8vhp

なぜかネットハックというゲーム名を思い出した

0767login:Penguin

2010/05/11(火) 05:04:43ID:PH2IO3s2

過疎ってるからメモでも各課。

masterからtopicへの差分が見たい
git diff master..topic
ただこれだとmasterが成長するにつれて差分も増える（topic放置でも）

git diff master...topic
こうすると、topicに枝分かれした時点でのmasterからtopicへの差分が表示される
つまりmasterって指定してるけど、実際使われるのは以前のmasterのある固定のポイント
なので「んでtopicってどんだけ何かやったの？」ってなった時に安定してdiffが取れる。

0768login:Penguin

2010/05/11(火) 22:24:57ID:Frr3rWMl

>>767
あれ？逆じゃない？
＞masterからtopicへの差分が見たい
のなら前者が良さそうな気がするんだ

git diff master..topicはtopicブランチだけがもってるコミットを表示せよ
git diff master...topicはmaster、topicだけがもってるコミットをそれぞれ表示せよ
だと思ってたんだけど俺の勘違いか

0769login:Penguin

2010/05/11(火) 22:38:53ID:Frr3rWMl

ん？何言ってんだ俺
途中からgit logの話になってるな。くそったれ
>>767の言うとおりだよちくしょう

0770login:Penguin

2010/05/12(水) 10:00:23ID:tQLSUqk6

ブランチ毎に文字コード変えれたりしますか？

0771login:Penguin

2010/05/12(水) 15:43:45ID:/mk0pC1k

エリック・レイモンドがメンテナに加わったんだね

0772login:Penguin

2010/05/13(木) 19:11:02ID:3F0hNVx/

cygwin 1.7のgit 1.6を使っています。
export LANG=ja_JP.UTF-8
してある環境です。

git-svnで引っ張ってきたsvnのリポジトリなのですが、
コミットログを検索したいのですがエラーがでてうまくいきません。。

$ git log --grep="うんこ"
fatal: command line, 'うんこ': illegal byte sequence

また同様にgit grepなどでも同じようにエラーがでます。
$ git grep "うんこおぁぁおおお"
fatal: command line, 'うんこおぁぁおおお': illegal byte sequence

マルチバイトを指定しない場合(英字とか)は問題ないようです。
ターミナルはckを使っており入力にはUTF-8を使っています。

正しく動かすにはどうしたらよいものでしょうか？また、原因としてはどこを疑ったものでしょうか？

0773772

2010/05/13(木) 19:18:45ID:3F0hNVx/

ログをUTF-8で入れた他のgitのリポジトリで試したところ同じ問題が起こり、git-svnは関係ないようでした。

また、coLinuxのUbuntu上では該当リポジトリに対して同様の動作、つまり
git log --grep="文明はどんどん発達していく…"
や
git grep "文明はどんどん発達していく…"
は問題ないようでした。
gitの問題ではなくcygwinかcygwin gitの問題ということでしょうか？

他のユーザーの方の環境できちんと動いているかお聞きしたいところです・・・

0774login:Penguin

2010/05/13(木) 22:02:02ID:2MNEOw/G

うんこはevilだからな

0775login:Penguin

2010/05/13(木) 22:32:28ID:DbFU2gKU

>>772
git help log のDISCUSSIONに書いてあるけど、commit logは
非NULのシーケンスとして解釈せずに格納してあるので、
grepする時にUTF-8に変換しようとして失敗してるんじゃない?
git help logの末尾の方には、commitした時にi18n.commitencoding
の値を記録している、と書いてあるけど、この値と実際のcommit log
の文字コードが一致していない、とかね。

0776772

2010/05/14(金) 10:20:48ID:Im+y6C3g

>>774
別にうんこじゃなくてもいいんですがｗ

>>775
git log --pretty=format:"%s %e"
で調べた所特にエンコーディングの記述はなく、
ログ自身はUTF-8であらかじめ入れてあるので、
git log をリダイレクトでテキストに出力した所、ログ自身は予想どうりUTF-8Nでした。

cygwinのときだけデフォルトの文字コードが一致しない？ということがあるのかなあ

LinuxでOKで、cygwinで問題というのが気になるところです・・・。

0777772

2010/05/14(金) 11:40:48ID:Im+y6C3g

"command line," とか "illegal byte sequence"でgitのソース検索したけど該当箇所でてこん・・・

0778login:Penguin

2010/05/14(金) 13:40:23ID:LmlSfb61

illegalなんちゃらって多分EILSEQをstrerror()に渡して得られるメッセージ
だと思うけど

0779772

2010/05/14(金) 22:57:56ID:Im+y6C3g

>>778
ああっと書き忘れてた、google code searchとかもついでに見てて、
EILSEQがひっかかったんでもgrepしてたんだけどgitソース内には見当たらなかった。
他の問題なのか・・・

0780login:Penguin

2010/05/15(土) 00:24:18ID:HTmR5ivn

それはlibiconvが出してんでしょ

0781login:Penguin

2010/05/17(月) 01:33:24ID:dnhW6nNk

TortoiseGitでSVNのリポジトリ使うのってどうやるの？

0782login:Penguin

2010/05/17(月) 19:05:56ID:6iXl9CjZ

git pull する時に、origin/masterのHEADではなく、過去のコミットを指定して行うことはできますか?

0783login:Penguin

2010/05/17(月) 19:27:07ID:bLG3BDZV

>>782
git pullはsvn updateみたいにHEADをコピーしているのでなく、過去の履歴も
含めて全部引っぱって来ている．　のでpullしたあと作業ポイントをcheckout
コマンドで指定する。

1) そのコミットがすでにブランチになっていれば

git checkout <branch>

2) ブランチになってなかったら

git checkout -b <new_branch> <start_point>

<new_branch> はブランチ名
<start_commit>は選択するコミット

これ、gitのtutorialだけ見てたら分からなかったんだけど、SVNと比較するこの
tutorialを見たら分かった。

GIt - SVN Crash Course
http://git.or.cz/course/svn.html

0784login:Penguin

2010/05/17(月) 22:06:20ID:6iXl9CjZ

>>783
サンクスです。それでいかせていただきます。

0785login:Penguin

2010/05/18(火) 22:33:48ID:6442L1FL

cvs,svnを使ってた人にとっては
git clone で落としてきた.gitは
CVSや.svnと同じようなものと思いがちやね。

>>747を見てバッカじゃねーのとか
思ったけど意外にこの勘違いを抱えたまま
毎回.gitを消してcloneしなおしてる人いるのかね。

0786login:Penguin

2010/05/18(火) 23:21:35ID:ID2y3O4e

いるかといえばいるんじゃないか。CVSやsubversionでも
そうしてきた人にとってはコピーしてきたリポジトリまで
消しちゃう無駄よりも、「ちゃんと動くことが分かる」状態
に戻ることのほうが重要だもの。

0787login:Penguin

2010/05/19(水) 00:23:37ID:zJinMQgP

分かりにくいと思ったのがcheckoutコマンドだな。　svnやcvs等の古典的な
checkoutコマンドとは随分意味が違う。　「ちゃんと動くことが分かる」状態に
どうやってもどせばいいんだろうと探している時、コマンドのリストの中の
checkoutコマンドの説明を見ようとは普通思わないんじゃないかな。　

0788login:Penguin

2010/05/19(水) 00:33:38ID:rEVii6OV

resetも二つの意味含んでるっぽくてわかりにくいな
unstageと分けてもいいと思う

0789login:Penguin

2010/06/01(火) 02:42:24ID:ke5Egb8T

git checkout を使って２つ前のコミットまで巻き戻したのですが、
git log すると一番最新のコミットと２番目に新しいコミットが見れなくなってしまいました。
もしかして、checkoutはコミットしたものを取り消してしまう危険なコマンドなんでしょうか？
最新のものに戻したい場合はどうすればいいのでしょう・・
てっきりsubversionのrevertと同じようなものだと思って使ったのですが・・
gitのrevertはリビジョンを戻して新しくコミットしなおす感じのようですが、
最近のコミットを取り消さず、単純にファイルを巻き戻すだけのコマンドはないのでしょうか？
教えていただけると嬉しいです。

0790login:Penguin

2010/06/01(火) 03:08:28ID:ib2iuIgt

>>789
ここまで的確に逆のこと言ってると釣りに見えるな。

git checkout HEAD~2 とかやったのなら、名無しブランチに居るだけだから
元のブランチをcheckoutすれば元どおり。

git revert は指定したコミットを逆パッチしたコミットを作ってくれる。
後戻りはしない。

当たり前にドキュメント読んだほうがいいよ。Subversionとは概念が違う。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html

0791login:Penguin

2010/06/01(火) 06:48:15ID:nEJNHOMY

タグとブランチで同じ名前のがある時にタグのfoo、ブランチのfoo
という指定はできるのでしょうか。ただfooとだけ指定すると
warning: refname 'foo' is ambiguous.
リポジトリはcvsimportで作ったもので、ファイルによってfooが
ブランチの場合とタグの場合があるためにこういう状態になって
います。

0792789

2010/06/01(火) 12:22:08ID:7rDC0XFu

>>790
レスありがとうございます。
自分がやったのは
git checkcout 862ed98d03863a826dca3246ee61d54264acae57
のような感じなんですが
あげて頂いたドキュメントを見ると、checkoutの説明のところに
「また、これが危険なコマンドであることも知っておかねばなりません。」
のように書かれていました。
やはり最新のコミット自体が消えてしまったように思えるのですが・・

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