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

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の説明のところに
「また、これが危険なコマンドであることも知っておかねばなりません。」
のように書かれていました。
やはり最新のコミット自体が消えてしまったように思えるのですが・・

0793login:Penguin

2010/06/01(火) 13:52:15ID:3Zl/kziy

コミットはなかなか消えない。
その下に、
>削除したブランチへのコミットや --amend コミットで上書きされた元のコミットでさえも復旧することができます
って書いてあるよ。

0794login:Penguin

2010/06/01(火) 14:35:10ID:rOsiehIq

>>791
ローカルブランチはheads/foo、タグはtags/fooで明示的に指定できますよ

0795login:Penguin

2010/06/01(火) 18:49:32ID:zlmZbFtl

>>792
reflogというものがあってだな

0796login:Penguin

2010/06/01(火) 20:05:14ID:WTjgN8Mk

>>792
＞「また、これが危険なコマンドであることも知っておかねばなりません。」
の部分は作業ディレクトリの情報が消えて、最新のコミットに戻されたって話だよ。

俺はgit以外のvcsをよく知らないけど、
subversionでも、レポジトリと個々人の作業ディレクトリってあるんだよね？
上の話は作業ディレクトリがレポジトリに戻されちゃって、
あなたの作業は消えましたよ、って話だから危険って書いてあるんじゃないのかしら。

0797login:Penguin

2010/06/01(火) 20:17:52ID:WTjgN8Mk

>>789は最新のコミットと２つ前のコミット間の、あるファイルのdiffでも見たいの？
そうなら、
git diff HEAD~2 -- (あるファイル)
っていうのはどう？
どうしてもcheckoutしたいならcheckoutした後、
git diff master.. -- (あるファイル)
でもいい

0798login:Penguin

2010/06/01(火) 20:24:44ID:WTjgN8Mk

>>792
あ、それと言うの忘れてた。
＞ git checkcout 862ed98d03863a826dca3246ee61d54264acae57
なら、>>790も言ってるけど一時的に別のブランチにいるよ。
git branchしてみれば、今までのブランチと別のブランチにいることが分かると思う。
git masterとかやれば元に戻れるんじゃないかな。
元がmasterなのかは知らないけど。

0799792

2010/06/02(水) 01:34:42ID:gi9ro0yc

色々レスありがとうございます。

状況としては、

最近のコミットに
49qayt928t4ht2
と
goghpghr9g9grh
というのがあったとして(文字列は適当です)
49qayt928t4ht2
が最新なのですが、一つ前のgoghpghr9g9grhに戻したいと思い、
git checkout goghpghr9g9grh
としたら、git log しても最新の
49qayt928t4ht2
が表示されなくなり、49qayt928t4ht2のコミットが消えてしまったように見える、
また最新の49qayt928t4ht2に状態を戻したくても、戻した方が分からない、といった感じだったのですが
git reflog と git resetのおかげでなんとかなりました。
勉強になります。ありがとうございました。

0800login:Penguin

2010/06/02(水) 05:38:06ID:tFFCKjtC

>>799
checkout直後なら以前チェックアウトしていたコミットがORIG HEADに格納されてるよ

0801login:Penguin

2010/06/02(水) 23:19:00ID:epvzW2MP

ORIG_HEADってマージのときに使うものかと思ってた
あれ？MERGE_HEADだっけ？

0802login:Penguin

2010/06/03(木) 00:57:02ID:4mfPiwdf

>>792
色々と突っ込みたい所はあるが、とりあえずチュートリアル読めば？

0803login:Penguin

2010/06/03(木) 08:35:19ID:dAM44TeX

>>799
git resetを使う状況じゃない。まずは>>798の内容を理解しよう。

0804login:Penguin

2010/06/03(木) 22:34:29ID:NRpX3vOy

git の branch コマンドは他のVCSみたいな、いわゆる枝(branch)を作るコマンドじゃないことを理解した方がいい。
単に自分のいる点に目印の旗を立ててるだけ。
commitやreset等で自分が動けば旗も移動する。

0805login:Penguin

2010/06/03(木) 22:37:18ID:2hMMbzRW

>>804
これの"create"は「作る」という事ではないのですか？

$ man git-branch

...
NAME
git-branch - List, create, or delete branches

0806login:Penguin

2010/06/03(木) 23:35:29ID:k3O2NdDL

>>805
まあ論理的には「作る」と考えて良いんだけど、、、
内部的には複数のコミットから親として参照されてればそれはブランチと言える
というぐらいで、特にbranchコマンドを使わなくても、ある履歴の途中の位置を
checkoutして何かコミットすれば分岐になるし、commit --amend とかで
やり直ししても以前のコミットと新しいコミットは分岐してる。
ただこの場合古いコミットは一見して行方不明になるけど、branchコマンドは
そこに旗を立てて移動しやすかったり自動でGCされないようにしたりしてる感じ。
reset とかいろいろ試してるうちに内部構造が分かるとそう思うようになったかな。

0807login:Penguin

2010/06/04(金) 00:02:52ID:/Cv0eiGe

各コミットは親を記憶してるから点から親を遡ることで枝を表現できる
ただ子の記憶は無いから自分の子供がどうなったかを辿る簡単な手段は無い
checkout等で移動してコミットが消えてるように見えるのはこの為

0808login:Penguin

2010/06/04(金) 06:08:20ID:PyuP7am3

>>805
自動更新してくれるタグとおもえばよいよ

0809login:Penguin

2010/06/05(土) 11:36:02ID:aEd5JAax

実はCVSでも似たようなことになっているんだけど、
自動GCがないということと、リポジトリの実装がファイル
単位なのでcvs adminコマンドで実現しようとすると1コミット
に関連するファイルに比例して面倒になる、という点が大きく違う。

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