トップページ⇒linux
984コメント325KB

git スレッド

■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin2007/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
0756login:Penguin2010/04/20(火) 09:29:20ID:4QSw7roF
rm -rf * して git checkout . はたまにやるな
早いし
0757login:Penguin2010/04/20(火) 10:51:57ID:wr/OBch+
"git clean -dfx"とか使わずにcloneし直して遅い遅い言ってる訳か。
0758login:Penguin2010/04/20(火) 22:18:12ID:3xiD65pL
>>750
ブランチごとにcloneって意味がわからん
git-svnは普通にSubversionのブランチも追いかけられるぞ？
0759login:Penguin2010/04/21(水) 08:24:48ID:yetyJ5AV
>>747
UNIX系の環境だったら .gitをコード生成するディレクトリの外に
置いてsymlink貼って使うとか、symlinkが使えない環境だったら
webdavサーバからclone --mirrorした(ローカルの)リポジトリから
git clone -s して使うとか、いろいろ回避策はあるでしょう。
0760login:Penguin2010/04/22(木) 12:54:59ID:hPfzumYq
git clean知らなかった。便利だ。
0761login:Penguin2010/04/22(木) 13:32:46ID:93pJE4US
1週間くらい前からライブラリはわりとできた気がするのだがGitHubで公開する勇気が出ない
めちゃくちゃ緊張して手が震えて駄目だ

公開することにした理由って何？
0762login:Penguin2010/04/22(木) 13:40:24ID:2lkoAWrr
>>761
だいじょうぶ、反響が皆無で逆に落ち込むから。
よっぽどインパクトのあるものかライフチェンジングなもの、もしくは宣伝しまくって煽ったりしない限り、
オープンソースソフトウェアの影響は徐々にくるものだから、気楽にやったほうがいいよ。
で、なにつくったの？
0763login:Penguin2010/04/22(木) 14:00:26ID:I4eCvKff
>>761
アドバイス求めたら結構くれるよ
0764login:Penguin2010/04/23(金) 00:44:22ID:S4Z1KuPQ
バイナリの場合は公開時の品質で悩むのもありだが
ソースつきなら
「俺はここまでやって方向示したのであとは凄い人が続きおね」
という思考で世間様にブン投げてOK

放っておけば誰かが使ったり誰かが紹介したり
もっといいものが出て忘れ去られたり
フォロアーどころか類似品すら出ずにカテゴリごと忘れられたりする
0765login:Penguin2010/04/23(金) 01:01:53ID:AfgDmnjX
きっと世の中には、とんでもなく使いやすくて斬新なアイデアかつ生産性の高い
ソフトウエア（の前身）たちが今日も日の目を見ないままひっそりとどこかにいるんだろうなあ
そういう革新的なソフトたち発掘するネット界の冒険者っていうのもおもしろそうだなあ

という電波をいましがた受信した
0766login:Penguin2010/04/25(日) 21:13:36ID:T3Ea8vhp
なぜかネットハックというゲーム名を思い出した
0767login:Penguin2010/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:Penguin2010/05/11(火) 22:24:57ID:Frr3rWMl
>>767
あれ？逆じゃない？
＞masterからtopicへの差分が見たい
のなら前者が良さそうな気がするんだ

git diff master..topicはtopicブランチだけがもってるコミットを表示せよ
git diff master...topicはmaster、topicだけがもってるコミットをそれぞれ表示せよ
だと思ってたんだけど俺の勘違いか
0769login:Penguin2010/05/11(火) 22:38:53ID:Frr3rWMl
ん？何言ってんだ俺
途中からgit logの話になってるな。くそったれ
>>767の言うとおりだよちくしょう
0770login:Penguin2010/05/12(水) 10:00:23ID:tQLSUqk6
ブランチ毎に文字コード変えれたりしますか？
0771login:Penguin2010/05/12(水) 15:43:45ID:/mk0pC1k
エリック・レイモンドがメンテナに加わったんだね
0772login:Penguin2010/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を使っています。

正しく動かすにはどうしたらよいものでしょうか？また、原因としてはどこを疑ったものでしょうか？
07737722010/05/13(木) 19:18:45ID:3F0hNVx/
ログをUTF-8で入れた他のgitのリポジトリで試したところ同じ問題が起こり、git-svnは関係ないようでした。

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

他のユーザーの方の環境できちんと動いているかお聞きしたいところです・・・
0774login:Penguin2010/05/13(木) 22:02:02ID:2MNEOw/G
うんこはevilだからな
0775login:Penguin2010/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
の文字コードが一致していない、とかね。
07767722010/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で問題というのが気になるところです・・・。
07777722010/05/14(金) 11:40:48ID:Im+y6C3g
"command line," とか "illegal byte sequence"でgitのソース検索したけど該当箇所でてこん・・・
0778login:Penguin2010/05/14(金) 13:40:23ID:LmlSfb61
illegalなんちゃらって多分EILSEQをstrerror()に渡して得られるメッセージ
だと思うけど
07797722010/05/14(金) 22:57:56ID:Im+y6C3g
>>778
ああっと書き忘れてた、google code searchとかもついでに見てて、
EILSEQがひっかかったんでもgrepしてたんだけどgitソース内には見当たらなかった。
他の問題なのか・・・
0780login:Penguin2010/05/15(土) 00:24:18ID:HTmR5ivn
それはlibiconvが出してんでしょ
0781login:Penguin2010/05/17(月) 01:33:24ID:dnhW6nNk
TortoiseGitでSVNのリポジトリ使うのってどうやるの？
0782login:Penguin2010/05/17(月) 19:05:56ID:6iXl9CjZ
git pull する時に、origin/masterのHEADではなく、過去のコミットを指定して行うことはできますか?
0783login:Penguin2010/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:Penguin2010/05/17(月) 22:06:20ID:6iXl9CjZ
>>783
サンクスです。それでいかせていただきます。
0785login:Penguin2010/05/18(火) 22:33:48ID:6442L1FL
cvs,svnを使ってた人にとっては
git clone で落としてきた.gitは
CVSや.svnと同じようなものと思いがちやね。

>>747を見てバッカじゃねーのとか
思ったけど意外にこの勘違いを抱えたまま
毎回.gitを消してcloneしなおしてる人いるのかね。
0786login:Penguin2010/05/18(火) 23:21:35ID:ID2y3O4e
いるかといえばいるんじゃないか。CVSやsubversionでも
そうしてきた人にとってはコピーしてきたリポジトリまで
消しちゃう無駄よりも、「ちゃんと動くことが分かる」状態
に戻ることのほうが重要だもの。
0787login:Penguin2010/05/19(水) 00:23:37ID:zJinMQgP
分かりにくいと思ったのがcheckoutコマンドだな。　svnやcvs等の古典的な
checkoutコマンドとは随分意味が違う。　「ちゃんと動くことが分かる」状態に
どうやってもどせばいいんだろうと探している時、コマンドのリストの中の
checkoutコマンドの説明を見ようとは普通思わないんじゃないかな。　
0788login:Penguin2010/05/19(水) 00:33:38ID:rEVii6OV
resetも二つの意味含んでるっぽくてわかりにくいな
unstageと分けてもいいと思う
0789login:Penguin2010/06/01(火) 02:42:24ID:ke5Egb8T
git checkout を使って ２つ前のコミットまで巻き戻したのですが、
git log すると一番最新のコミットと２番目に新しいコミットが見れなくなってしまいました。
もしかして、checkoutはコミットしたものを取り消してしまう危険なコマンドなんでしょうか？
最新のものに戻したい場合はどうすればいいのでしょう・・
てっきりsubversionのrevertと同じようなものだと思って使ったのですが・・
gitのrevertはリビジョンを戻して新しくコミットしなおす感じのようですが、
最近のコミットを取り消さず、単純にファイルを巻き戻すだけのコマンドはないのでしょうか？
教えていただけると嬉しいです。
0790login:Penguin2010/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:Penguin2010/06/01(火) 06:48:15ID:nEJNHOMY
タグとブランチで同じ名前のがある時にタグのfoo、ブランチのfoo
という指定はできるのでしょうか。ただfooとだけ指定すると
warning: refname 'foo' is ambiguous.
リポジトリはcvsimportで作ったもので、ファイルによってfooが
ブランチの場合とタグの場合があるためにこういう状態になって
います。
07927892010/06/01(火) 12:22:08ID:7rDC0XFu
>>790
レスありがとうございます。
自分がやったのは
git checkcout 862ed98d03863a826dca3246ee61d54264acae57
のような感じなんですが
あげて頂いたドキュメントを見ると、checkoutの説明のところに
「また、これが危険なコマンドであることも知っておかねばなりません。」
のように書かれていました。
やはり最新のコミット自体が消えてしまったように思えるのですが・・
0793login:Penguin2010/06/01(火) 13:52:15ID:3Zl/kziy
コミットはなかなか消えない。
その下に、
>削除したブランチへのコミットや --amend コミットで上書きされた元のコミットでさえも復旧することができます
って書いてあるよ。
0794login:Penguin2010/06/01(火) 14:35:10ID:rOsiehIq
>>791
ローカルブランチはheads/foo、タグはtags/fooで明示的に指定できますよ
0795login:Penguin2010/06/01(火) 18:49:32ID:zlmZbFtl
>>792
reflogというものがあってだな
0796login:Penguin2010/06/01(火) 20:05:14ID:WTjgN8Mk
>>792
＞ 「また、これが危険なコマンドであることも知っておかねばなりません。」
の部分は作業ディレクトリの情報が消えて、最新のコミットに戻されたって話だよ。

俺はgit以外のvcsをよく知らないけど、
subversionでも、レポジトリと個々人の作業ディレクトリってあるんだよね？
上の話は作業ディレクトリがレポジトリに戻されちゃって、
あなたの作業は消えましたよ、って話だから危険って書いてあるんじゃないのかしら。
0797login:Penguin2010/06/01(火) 20:17:52ID:WTjgN8Mk
>>789は最新のコミットと２つ前のコミット間の、あるファイルのdiffでも見たいの？
そうなら、
git diff HEAD~2 -- (あるファイル)
っていうのはどう？
どうしてもcheckoutしたいならcheckoutした後、
git diff master.. -- (あるファイル)
でもいい
0798login:Penguin2010/06/01(火) 20:24:44ID:WTjgN8Mk
>>792
あ、それと言うの忘れてた。
＞ git checkcout 862ed98d03863a826dca3246ee61d54264acae57
なら、>>790も言ってるけど一時的に別のブランチにいるよ。
git branchしてみれば、今までのブランチと別のブランチにいることが分かると思う。
git masterとかやれば元に戻れるんじゃないかな。
元がmasterなのかは知らないけど。
07997922010/06/02(水) 01:34:42ID:gi9ro0yc
色々レスありがとうございます。

状況としては、

最近のコミットに
49qayt928t4ht2
と
goghpghr9g9grh
というのがあったとして(文字列は適当です)
49qayt928t4ht2
が最新なのですが、一つ前のgoghpghr9g9grhに戻したいと思い、
git checkout goghpghr9g9grh
としたら、git log しても最新の
49qayt928t4ht2
が表示されなくなり、49qayt928t4ht2のコミットが消えてしまったように見える、
また最新の49qayt928t4ht2に状態を戻したくても、戻した方が分からない、といった感じだったのですが
git reflog と git resetのおかげでなんとかなりました。
勉強になります。ありがとうございました。
0800login:Penguin2010/06/02(水) 05:38:06ID:tFFCKjtC
>>799
checkout直後なら以前チェックアウトしていたコミットがORIG HEADに格納されてるよ
0801login:Penguin2010/06/02(水) 23:19:00ID:epvzW2MP
ORIG_HEADってマージのときに使うものかと思ってた
あれ？MERGE_HEADだっけ？
0802login:Penguin2010/06/03(木) 00:57:02ID:4mfPiwdf
>>792
色々と突っ込みたい所はあるが、とりあえずチュートリアル読めば？
0803login:Penguin2010/06/03(木) 08:35:19ID:dAM44TeX
>>799
git resetを使う状況じゃない。まずは>>798の内容を理解しよう。
0804login:Penguin2010/06/03(木) 22:34:29ID:NRpX3vOy
git の branch コマンドは他のVCSみたいな、いわゆる枝(branch)を作るコマンドじゃないことを理解した方がいい。
単に自分のいる点に目印の旗を立ててるだけ。
commitやreset等で自分が動けば旗も移動する。
0805login:Penguin2010/06/03(木) 22:37:18ID:2hMMbzRW
>>804
これの"create"は「作る」という事ではないのですか？

$ man git-branch

...
NAME
git-branch - List, create, or delete branches
0806login:Penguin2010/06/03(木) 23:35:29ID:k3O2NdDL
>>805
まあ論理的には「作る」と考えて良いんだけど、、、
内部的には複数のコミットから親として参照されてればそれはブランチと言える
というぐらいで、特にbranchコマンドを使わなくても、ある履歴の途中の位置を
checkoutして何かコミットすれば分岐になるし、commit --amend とかで
やり直ししても以前のコミットと新しいコミットは分岐してる。
ただこの場合古いコミットは一見して行方不明になるけど、branchコマンドは
そこに旗を立てて移動しやすかったり自動でGCされないようにしたりしてる感じ。
reset とかいろいろ試してるうちに内部構造が分かるとそう思うようになったかな。
0807login:Penguin2010/06/04(金) 00:02:52ID:/Cv0eiGe
各コミットは親を記憶してるから点から親を遡ることで枝を表現できる
ただ子の記憶は無いから自分の子供がどうなったかを辿る簡単な手段は無い
checkout等で移動してコミットが消えてるように見えるのはこの為
0808login:Penguin2010/06/04(金) 06:08:20ID:PyuP7am3
>>805
自動更新してくれるタグとおもえばよいよ
0809login:Penguin2010/06/05(土) 11:36:02ID:aEd5JAax
実はCVSでも似たようなことになっているんだけど、
自動GCがないということと、リポジトリの実装がファイル
単位なのでcvs adminコマンドで実現しようとすると1コミット
に関連するファイルに比例して面倒になる、という点が大きく違う。
0810login:Penguin2010/06/05(土) 20:57:10ID:zknULthJ
git svn clone すると Using higher level と言われて取ってこれないんですが、
どうしたらいいんでしょうか？

$ git svn clone --prefix svn/ -s svn+ssh://xxx/var/svn/project
Initialized empty Git repository in /Users/alice/src/project/.git/
Using higher level of URL: svn+ssh://xxx/var/svn/project => svn+ssh://xxx/var/svn
error: git-svn died of signal 13

svn ls すると見えてます。svn co もできます。

$ svn ls svn+ssh://xxx/var/svn/project
branches/
tags/
trunk/

バージョン
$ git --version
git version 1.7.1

試しにローカルに作ったsvnリポジトリに対しては、リポジトリ内のサブディレクトリに
相当するプロジェクトを同様のコマンドで取ってこれます。
$ git svn clone --prefix svn/ -s file:///var/svn/project2 → 成功
08118102010/06/05(土) 23:35:57ID:zknULthJ
試行錯誤してたらローカルのsvnリポジトリに対してでも svn+ssh だと失敗
git svn clone --prefix svn/ -s file:///var/svn/project2 → 成功
git svn clone --prefix svn/ -s svn+ssh://localhost/var/svn/project2 → 失敗
git svn clone -s svn+ssh://localhost/var/svn/project2 → 失敗
git svn clone svn+ssh://localhost/var/svn/project2 → 失敗
git svn clone svn+ssh://localhost/var/svn/project2/trunk → 成功

もしかしてssh経由だと最後の方法しかダメ？
0812login:Penguin2010/06/06(日) 22:17:11ID:KNE6oozw
git svn clone svn+ssh://localhost/var/svn/project2 に
--trunk trunk オプションを適用したらどうなる？
08138102010/06/06(日) 23:06:25ID:DDm/Y5Pc
>>812
レスありがとうございます。
次の2つが正しく動作するのを確認後、
$ svn co svn+ssh://localhost/var/svn/project2/trunk project2
$ git svn clone --trunk trunk file:///var/svn/project2

svn+ssh と --trunk trunk の組み合わせを試したんですが >>810 のときと同様のエラーになります。
$ git svn clone --trunk trunk svn+ssh://localhost/var/svn/project2
Initialized empty Git repository in /Users/alice/src/project2/.git/
Using higher level of URL: svn+ssh://localhost/var/svn/project2 => svn+ssh://localhost/var/svn
error: git-svn died of signal 13

が、あれこれ試していたらここで中途半端にできた project2 ディレクトリ(中身は.gitだけ)を削除せずに、再び
git svn clone --trunk trunk svn+ssh://localhost/var/svn/project2
を実行するとcloneできました。
つまり --trunk trunk 付きで二回実行するとcloneできました。

それなら -s をつけた場合も二回実行すればいけるかと、試したんですが二回目も失敗します
二回目は「error: git-svn died of signal 13」だけが表示されます。
08148102010/06/07(月) 00:13:59ID:J3cMfgEo
Subversion のリビジョン番号が大きいと git svn clone が失敗するので、git svn fetch を使うと良い | cooldaemon's memo
http://cooldaemon.tumblr.com/post/71989299/subversion-git-svn-clone-git-svn

ローカルに作ったSVNリポジトリのHEADはリビジョン1なんですが、
上のサイトを参考に、git svn clone に失敗したあとにできたディレクトリに移動したあと
git svn fetch を実行したところファイルを取ってくることができました。
0815login:Penguin2010/06/08(火) 13:31:10ID:rxszYzgC
基本を教えてください。自前のプロジェクトをgithubに上げました。

ローカルのリポジトリフォルダで直接ソース修正し,
git add, git commit -m 'hoge', git push,
という手順を踏むのは、正しい手順なのでしょうか？

ブランチを切ってそれをmerge、というのも見つけたのですが、
違いが何かがまだ理解できません。ローカルの作業フォルダを
別に複製してそこで作業する、という意味ですか？

ググってもいまいち飲み込めず・・・用語が難しくて理解しづらいです。
0816login:Penguin2010/06/08(火) 17:27:44ID:ioTeze1h
>>815
よくわからなかったら、既存のものをforkしたのでなければ、
bitbucketを使いましょう。
0817login:Penguin2010/06/08(火) 17:29:09ID:8e1WnVu/
>>815
はい。正しいです。ブランチは新しい機能とメインの開発を分けて開発したい場合に使ったりします。
ローカルリポジトリ内で完結するので新しくフォルダをつくる必要はないです。branchとcheckoutコマンドでいろいろ遊んでみるとよいかも。
0818login:Penguin2010/06/08(火) 17:35:19ID:2UFah327
質問があります。(スレ違いでしたらすいません)

メインのソースツリーが subversion で管理されており、ローカル環境では、git-svn を使って、ソースのやりとりを行っています。

あるとき、ローカルのツリーを壊してしまったのか、
git checkout master
を実行すると、
and have XXXX and YYYY different commit(s) each, respectively.

という行が表示されています。
さらに、git pull を実行すると、git pull が失敗します。

ローカルのソースツリーを正常な状態にしたいのですが、ローカルにあるソースを全て削除し、さらに .git ディレクトリも削除したのち、改めて、git svn clone をしないといけないのでしょうか。

リビジョン YYYY までの修正分までは残しておき、YYYY + 1〜XXXX までのリビジョンを削除したのち、改めて、git svn rebase で、YYYY + 1 以降の差分を取得したいのですが、その様なことは可能でしょうか。もし、可能でしたら、どうしたらできるのでしょうか。

どうかよろしくお願い致します。
0819login:Penguin2010/06/08(火) 17:57:50ID:KwHWNnWZ
>>818
そのメッセージはマージ対象のブランチと現在のブランチが分岐してるよ、
って教えてくれてるんだけど、git-svnでもそれ出たっけな？
それにgit pull って、git-svn では使わないよ？

実際、svnのことは一旦忘れて、ドキュメントちゃんと読んだ方がいいよ。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html
大体一緒でしょ、っていうつもりでノリで触ってるとかえって回り道。
08208152010/06/08(火) 18:00:17ID:rxszYzgC
>>816
いえ、githubにしろって言われたもので仕方なく・・・

>>817
ありがとうございます。助かります。

>ローカルリポジトリ内で完結するので新しくフォルダをつくる必要はない
ということは、checkoutするとブランチ間で異なるファイルがごっそり
差し替えされるということですね。試してみます。
0821login:Penguin2010/06/08(火) 18:21:21ID:KwHWNnWZ
てかさ、ドキュメント読まないやつ多すぎだろ。
何回ProgitとatwikiのURL貼らせんだよ。

他の便利ソフトみたいに、つまづいたとこを逐次誰かに教えて貰って、
とりあえず使えるようになればそれでOK、っていうものとは違うんだって
ことぐらい分かれよ。分散型使ったことなくてsvnしか知らないようなら
尚更ダメだろ。ソースコード管理するのに手探りみたいな状態でやってて
不安じゃないのか？

たいして時間かかんないから、ドキュメント読もうぜ。Progitも公式チュートリアルも
親切丁寧に書いてあるから。はあはあ。
0822login:Penguin2010/06/08(火) 18:33:01ID:ioTeze1h
Subversionのブランチとタグが要らない混乱を生んでいる気がする。
CVSからさわっていれば、ブランチもタグもすんなり理解できるのだが。
0823login:Penguin2010/06/08(火) 21:49:57ID:2UFah327
>>819
>>821
>>822
819 さんに教えて頂きましたドキュメントなどを参考して、ローカル環境を戻してみます。
git svn rebase とするべきところ、ついつい、git pull と打ってしまう私が悪いんで。
また、さっきもやってしまって、マージできないとエラーが出たソースを元に戻していました。


0824login:Penguin2010/06/11(金) 04:51:28ID:fuz3kvBd
質問です。

＜環境＞
$ uname
CYGWIN_NT-5.1

$ git --version
git version 1.7.0.4


歴代のコミットの状態を別のディレクトリへcheckoutできないものでしょうか。
今は、コミットIDの一覧からすべてをtar ballに吐き出して全部展開しなおす、
という手順をとっています。
もっと楽な方法(git clone [commit ID]とか)ご存知ではないでしょうか。
0825login:Penguin2010/06/11(金) 05:10:03ID:2NWqNXbx
>>824
git-checkout-indexでできるよ
0826login:Penguin2010/06/11(金) 08:34:44ID:Ce5oaCgs
$CHECKOUT_ROOTの下に、各バージョンの短いハッシュの名前の
ディレクトリで展開するone-liner
git log --format=%h |while read h; do git archive --format=tar --prefix=$h/ |gtar -C $CHECKOUT_ROOT -xf -; done

各ディレクトリでもgitの操作をしたいならgit clone -sでリポジトリを
作ってからそこでcheckoutするようにしたらいいと思う。
0827login:Penguin2010/06/11(金) 12:49:38ID:CxOtHYvF
>>825
ありがとう。svn exportというのは意図したコマンドのようなのですが、
git-checkout-indexのヘルプにはコミットID指定の引数が見当たらないような。

>>826
なるほど。あー。--outputオプションの意味がわかった気がしました。

せっかくなんで昔見つけたtipsを活かしてみました。
ttp://whileimautomaton.net/2009/05/08003459

export-all = "!$SHELL -c ' \n\
cnt=1 \n\
git log --format=%h --reverse |while read h; do \n\
git archive --format=tar --prefix=$(printf %03d-%s/ $cnt $h) $h |tar -C ../hoge -xf - \n\
cnt=`expr $cnt + 1` \n\
done \n\
' __dummy__"

勝手に変えたところ
・git archive に$hを渡した。エラーになったので。
・gtar->tar。入っていなかったので。
・コミットは時系列順に、３桁連番をつける。

今のところ
・吐き出す先が../hoge固定
・なにがなんでも全コミットが対象
ですが、今日のところは満足なので放っときます。

有難う。楽しかったです。
0828login:Penguin2010/06/11(金) 14:01:17ID:xMk4QMQl
git commit -m c1
git commit -m c2
git commit -m c3
としたときの次のコミットを c3 に混ぜるには
git commit --amend
ですが、c2 に混ぜるにはどうやるんでしょう？
0829login:Penguin2010/06/11(金) 16:33:46ID:CxOtHYvF
>>828
ttp://progit.org/book/ja/ch6-4.html
08308282010/06/12(土) 20:32:34ID:EYPWrV4V
>>829
そのサイトを参考にやったらなんとかできました。ありがとうございます！
一応、自分用の実験メモを貼っときます。
$ echo x > x1.txt; git add .; git commit -a -m c1
$ echo x > x2.txt; git add .; git commit -a -m c2
$ echo x > x3.txt; git add .; git commit -a -m c3
c2 に含めたい作業分を c4 としてとりあえずコミットする(コミットしないと git rebase できなかったので)
$ echo x > x4.txt; git add .; git commit -a -m c4
c2 が何個前か確認すると3つ前だとわかる
$ git log HEAD~3..HEAD --oneline
e4b2fdb c4
cf77615 c3
09e1d42 c2
それを引数に git rebase -i を実行する
$ git rebase -i HEAD~3
エディタが起動して c2 c3 c4 の順に出ているので下のように c4 の pick を squash に変更して c2 の直後に移動させて終了すると
pick 09e1d42 c2
squash e4b2fdb c4
pick cf77615 c3
再びエディタが起動して c2 と c4 が出てくるのでコミットメッセージを調整して終了する。
再び確認するとc2とc4が一緒になっていることがわかる(コミットメッセージを c2c4 にしたので)
$ git log HEAD~3..HEAD --oneline
0fec832 c3
53d09e5 c2c4
61b0400 c1
0831login:Penguin2010/06/12(土) 21:25:08ID:MYEOj4or
rebase -iを使いまくる快感を覚えるとgitから逃れられなくなる。
0832login:Penguin2010/06/12(土) 22:25:59ID:qHF7b2tG
>>827
ブランチを作ったりrebaseしたりすると使わなくなるaliasだと思う。
0833login:Penguin2010/06/17(木) 22:46:57ID:ic50UB3Y
TortoiseGitでSVNリポジトリを使うのってどうやるんですか？
0834login:Penguin2010/06/19(土) 15:28:13ID:AdBXeY0E
>>833
ここはLinux板だからプログラム板行った方が良いんでない？
0835login:Penguin2010/06/19(土) 17:18:17ID:e4H00FQJ
というかTortoiseSVN使えよ
0836login:Penguin2010/06/19(土) 18:13:51ID:4IVjSb/t
>>833
TortoiseGitにgit-svn機能が追加されたのは0.8.1.0からだそうだが、
あなたのバージョンはいくつなわけ?
0837login:Penguin2010/06/19(土) 23:13:28ID:EutOiIFE
>>834
ム板にgitスレがない
つーかなんで>>1はここに立てた…？
リーナスが作ったからか。そうか。
0838login:Penguin2010/06/19(土) 23:25:04ID:4f8lOGK6
git log --graph使いやすい。
msysgitのgitkは文字化けするから助かる
0839login:Penguin2010/06/19(土) 23:30:52ID:5cDyCRiO
>>837
2007年の時点だと、Linuxでしかまともに使ってる人居なかったんじゃないか
0840login:Penguin2010/06/20(日) 00:31:12ID:cdOp7QHw
>>837
ム板にSVNならあるよ、ってこっちにもあるね。
0841login:Penguin2010/06/20(日) 22:04:20ID:7uPWjQgS
とあるファイルをレポジトリに追加しようと思って、git add File
ってやった後、コミットする前にgit checkout -f 〜ってやったら、
当然追加したFileは消えてるよね。＼(^o^)/

これって、復活させることは無理？
要するに、消えたファイルをサルベージしたいんです...(T^T)
0842login:Penguin2010/06/20(日) 22:07:50ID:1ShQeJBQ
forceって指示出してるからねぇ…
0843login:Penguin2010/06/20(日) 22:13:59ID:7uPWjQgS
あきらめて作り直す....べきですか
add *.cs
なんて一括で追加したものだから...
いい週末になりました。(゜Д゜)
0844login:Penguin2010/06/20(日) 22:46:22ID:/lqjlFiM
ファイルそのものは .git/objects にころがってるけど探すのが大変ですねー

$ git init; touch .gitignore; git add .gitignore; git commit -m 'init'
Initialized empty Git repository in /home/a/tmp/test-git/.git/
[master (root-commit) 8f89495] init
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
$ echo hogehoge > fuga
$ git add .
$ ls
fuga
$ git checkout -f master
Already on 'master'
$ ls
$ LANG=C tree .git/objects
.git/objects
|-- 82
| `-- e3a754b6a0fcb238b03c0e47d05219fbf9cf89
|-- 8f
| `-- 894951217914f4a29681fba7f7917acc034322
|-- e6
| `-- 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
|-- e9
| `-- bc11025c28829eedf6d30cd3b65628648cad5f
|-- info
`-- pack
$ git show e9bc11025c28829eedf6d30cd3b65628648cad5f
hogehoge
0845login:Penguin2010/06/21(月) 03:55:25ID:g1rTD290
>>844
そっか、indexに入れたのが残ってるのか！

>>843
＞いい週末になりました。(゜Д゜)
サルベージがんばれ！
0846login:Penguin2010/06/21(月) 21:41:56ID:GDaRrD9a
>>844-845
ありがとぉ〜〜。

> ファイルそのものは .git/objects にころがってるけど探すのが大変ですねー

これで思い出しました。
数日前にgit stashで検索したときに見つけたこのページ↓
ttp://d.hatena.ne.jp/t-wada/20090407/p1

このページをもとにgit fsck --cacheなどの出力から「〜blob」を抽出し、
それを順次git showしたら、なんだかそれっぽいものが出てきた〜〜(^○^)
ということで、おかげさまでサルベージ完了です。
いい週明けになりました。(^-^)
取り急ぎお礼まで。

0847login:Penguin2010/06/23(水) 04:04:24ID:JeKYkEUM
あああ・・・
ディレクトリ間違ってGITROOTで

find ./ -type f|xargs -i nkf -w -Ls --overwrite {}

やってしまった。オプション間違ってるし。
$ git log
error: non-monotonic index .git/objects/pack/pack-13ad494e745c9bd63ad500c1a376db3b34848631.idx
error: inflate: data stream error (invalid code lengths set)
fatal: object 9e521bc6c6454973b0d2df293bbe6288ae1e9156 is corrupted


$ git fsck
error: non-monotonic index .git/objects/pack/pack-13ad494e745c9bd63ad500c1a376db3b34848631.idx
error: inflate: data stream error (invalid literal/lengths set)
fatal: object 006d1163b9f7c9ee57bde708ada9e791a769bdc8 is corrupted


さすがにこれはもうアウト？
08488472010/06/23(水) 09:14:25ID:LED7N0iF
$ rm .git/index
$ git reset

でもだめだ…

.git/objects/00とかの下のコミットID名（？）をgit showしても一緒だよ。

おろろーん
0849login:Penguin2010/06/23(水) 13:37:25ID:vPPSucp0
xargsってこわいなやっぱ
0850login:Penguin2010/06/23(水) 20:53:37ID:RwfTLv2f
っ「Daily backup」
08518472010/06/24(木) 16:37:14ID:zb2GzD4D
うん。
途中まではサーバリポジトリにあったから、途中の履歴とブランチは諦ましたとさ。
0852login:Penguin2010/06/24(木) 23:46:17ID:PrxiwgIJ
あるプロジェクトでgit使い始めたんだが、その時点より古いコード一式が出てきた。
これを、過去の履歴として最初のコミットより前に登録することってできる？
0853login:Penguin2010/06/25(金) 00:01:43ID:icPu4CVC
>852
その古いコードからはじまる歴史を作るのが良いんじゃね。
その歴史をもったリポジトリを正にしてしまう。
0854login:Penguin2010/06/26(土) 00:44:08ID:cyQi64aO
あとからあとから、遺産が見つかるのよ。
でも、歴史はある時点のを基点として、進んでいってる。
つまり、遺産が見つかる度にリポジトリを作り直すってこと？
0855login:Penguin2010/06/26(土) 04:17:55ID:w2I5qyES
>>854
過去を改竄した上に、現在に至る道筋を全て書き換えるのだから、そうするしかないね。

ただ歴史の参考書として使うのが目的であれば、遺産専用のリポジトリを作って、
現実の流れとは切り離してみたら？
■ このスレッドは過去ログ倉庫に格納されています