10/04/19 16:41:09 4DqhZF3F
>>747
＞中間コード生成する類のコードだと余計ファイルを一掃したくなるので
＞中央からクローンする頻度が上がる、クローンが遅いのは痛い。
中間コードの生成とクローンの頻度に何の関係があるの？ ignoreとかmakeとか使えないの？
てかクローン（全履歴取得）は最初だけでその後はフェッチ。中央扱いの場所へのコミット頻度が
高ければ、必然的にフェッチする頻度も増すだろうが。
社外とクローズドなソースコードのやりとりするなら会社責任者の認証を受けるべきだし、
そんならちゃんとした手順踏んで相手方とトンネル掘るなりしてsshでやるべきじゃないかと思う。
752:login:Penguin
10/04/19 22:26:52 9lqpgC5I
件の中間生成物を掃除するために、リポジトリまるごと"rm -rf *"で闇に葬ってから
"git clone"してたりするんでないかと。
753:login:Penguin
10/04/20 00:11:21 dxBJHbyQ
うわー
754:login:Penguin
10/04/20 04:50:52 pVtIppVL
普通中間生成物削除する何らかの手段用意するよなあ。
Makefileのcleanターゲットとかさー
755:login:Penguin
10/04/20 08:39:49 1DvR0uQW
んだよそんな低レベルうんこ野郎が、糞だのボゲだのってDISってたのかよ。
756:login:Penguin
10/04/20 09:29:20 4QSw7roF
rm -rf * して git checkout . はたまにやるな
早いし
757:login:Penguin
10/04/20 10:51:57 wr/OBch+
"git clean -dfx"とか使わずにcloneし直して遅い遅い言ってる訳か。
758:login:Penguin
10/04/20 22:18:12 3xiD65pL
>>750
ブランチごとにcloneって意味がわからん
git-svnは普通にSubversionのブランチも追いかけられるぞ？
759:login:Penguin
10/04/21 08:24:48 yetyJ5AV
>>747
UNIX系の環境だったら .gitをコード生成するディレクトリの外に
置いてsymlink貼って使うとか、symlinkが使えない環境だったら
webdavサーバからclone --mirrorした(ローカルの)リポジトリから
git clone -s して使うとか、いろいろ回避策はあるでしょう。
760:login:Penguin
10/04/22 12:54:59 hPfzumYq
git clean知らなかった。便利だ。
761:login:Penguin
10/04/22 13:32:46 93pJE4US
1週間くらい前からライブラリはわりとできた気がするのだがGitHubで公開する勇気が出ない
めちゃくちゃ緊張して手が震えて駄目だ
公開することにした理由って何？
762:login:Penguin
10/04/22 13:40:24 2lkoAWrr
>>761
だいじょうぶ、反響が皆無で逆に落ち込むから。
よっぽどインパクトのあるものかライフチェンジングなもの、もしくは宣伝しまくって煽ったりしない限り、
オープンソースソフトウェアの影響は徐々にくるものだから、気楽にやったほうがいいよ。
で、なにつくったの？
763:login:Penguin
10/04/22 14:00:26 I4eCvKff
>>761
アドバイス求めたら結構くれるよ
764:login:Penguin
10/04/23 00:44:22 S4Z1KuPQ
バイナリの場合は公開時の品質で悩むのもありだが
ソースつきなら
「俺はここまでやって方向示したのであとは凄い人が続きおね」
という思考で世間様にブン投げてOK
放っておけば誰かが使ったり誰かが紹介したり
もっといいものが出て忘れ去られたり
フォロアーどころか類似品すら出ずにカテゴリごと忘れられたりする
765:login:Penguin
10/04/23 01:01:53 AfgDmnjX
きっと世の中には、とんでもなく使いやすくて斬新なアイデアかつ生産性の高い
ソフトウエア（の前身）たちが今日も日の目を見ないままひっそりとどこかにいるんだろうなあ
そういう革新的なソフトたち発掘するネット界の冒険者っていうのもおもしろそうだなあ
という電波をいましがた受信した
766:login:Penguin
10/04/25 21:13:36 T3Ea8vhp
なぜかネットハックというゲーム名を思い出した
767:login:Penguin
10/05/11 05:04:43 PH2IO3s2
過疎ってるからメモでも各課。
masterからtopicへの差分が見たい
git diff master..topic
ただこれだとmasterが成長するにつれて差分も増える（topic放置でも）
git diff master...topic
こうすると、topicに枝分かれした時点でのmasterからtopicへの差分が表示される
つまりmasterって指定してるけど、実際使われるのは以前のmasterのある固定のポイント
なので「んでtopicってどんだけ何かやったの？」ってなった時に安定してdiffが取れる。
768:login:Penguin
10/05/11 22:24:57 Frr3rWMl
>>767
あれ？逆じゃない？
＞masterからtopicへの差分が見たい
のなら前者が良さそうな気がするんだ
git diff master..topicはtopicブランチだけがもってるコミットを表示せよ
git diff master...topicはmaster、topicだけがもってるコミットをそれぞれ表示せよ
だと思ってたんだけど俺の勘違いか
769:login:Penguin
10/05/11 22:38:53 Frr3rWMl
ん？何言ってんだ俺
途中からgit logの話になってるな。くそったれ
>>767の言うとおりだよちくしょう
770:login:Penguin
10/05/12 10:00:23 tQLSUqk6
ブランチ毎に文字コード変えれたりしますか？
771:login:Penguin
10/05/12 15:43:45 /mk0pC1k
エリック・レイモンドがメンテナに加わったんだね
772:login:Penguin
10/05/13 19:11:02 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を使っています。
正しく動かすにはどうしたらよいものでしょうか？また、原因としてはどこを疑ったものでしょうか？
773:772
10/05/13 19:18:45 3F0hNVx/
ログをUTF-8で入れた他のgitのリポジトリで試したところ同じ問題が起こり、git-svnは関係ないようでした。
また、coLinuxのUbuntu上では該当リポジトリに対して同様の動作、つまり
git log --grep="文明はどんどん発達していく…"
や
git grep "文明はどんどん発達していく…"
は問題ないようでした。
gitの問題ではなくcygwinかcygwin gitの問題ということでしょうか？
他のユーザーの方の環境できちんと動いているかお聞きしたいところです・・・
774:login:Penguin
10/05/13 22:02:02 2MNEOw/G
うんこはevilだからな
775:login:Penguin
10/05/13 22:32:28 DbFU2gKU
>>772
git help log のDISCUSSIONに書いてあるけど、commit logは
非NULのシーケンスとして解釈せずに格納してあるので、
grepする時にUTF-8に変換しようとして失敗してるんじゃない?
git help logの末尾の方には、commitした時にi18n.commitencoding
の値を記録している、と書いてあるけど、この値と実際のcommit log
の文字コードが一致していない、とかね。
776:772
10/05/14 10:20:48 Im+y6C3g
>>774
別にうんこじゃなくてもいいんですがｗ
>>775
git log --pretty=format:"%s %e"
で調べた所特にエンコーディングの記述はなく、
ログ自身はUTF-8であらかじめ入れてあるので、
git log をリダイレクトでテキストに出力した所、ログ自身は予想どうりUTF-8Nでした。
cygwinのときだけデフォルトの文字コードが一致しない？ということがあるのかなあ
LinuxでOKで、cygwinで問題というのが気になるところです・・・。
777:772
10/05/14 11:40:48 Im+y6C3g
"command line," とか "illegal byte sequence"でgitのソース検索したけど該当箇所でてこん・・・
778:login:Penguin
10/05/14 13:40:23 LmlSfb61
illegalなんちゃらって多分EILSEQをstrerror()に渡して得られるメッセージ
だと思うけど
779:772
10/05/14 22:57:56 Im+y6C3g
>>778
ああっと書き忘れてた、google code searchとかもついでに見てて、
EILSEQがひっかかったんでもgrepしてたんだけどgitソース内には見当たらなかった。
他の問題なのか・・・
780:login:Penguin
10/05/15 00:24:18 HTmR5ivn
それはlibiconvが出してんでしょ
781:login:Penguin
10/05/17 01:33:24 dnhW6nNk
TortoiseGitでSVNのリポジトリ使うのってどうやるの？
782:login:Penguin
10/05/17 19:05:56 6iXl9CjZ
git pull する時に、origin/masterのHEADではなく、過去のコミットを指定して行うことはできますか?
783:login:Penguin
10/05/17 19:27:07 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
URLﾘﾝｸ(git.or.cz)
784:login:Penguin
10/05/17 22:06:20 6iXl9CjZ
>>783
サンクスです。それでいかせていただきます。
785:login:Penguin
10/05/18 22:33:48 6442L1FL
cvs,svnを使ってた人にとっては
git clone で落としてきた.gitは
CVSや.svnと同じようなものと思いがちやね。
>>747を見てバッカじゃねーのとか
思ったけど意外にこの勘違いを抱えたまま
毎回.gitを消してcloneしなおしてる人いるのかね。
786:login:Penguin
10/05/18 23:21:35 ID2y3O4e
いるかといえばいるんじゃないか。CVSやsubversionでも
そうしてきた人にとってはコピーしてきたリポジトリまで
消しちゃう無駄よりも、「ちゃんと動くことが分かる」状態
に戻ることのほうが重要だもの。
787:login:Penguin
10/05/19 00:23:37 zJinMQgP
分かりにくいと思ったのがcheckoutコマンドだな。 svnやcvs等の古典的な
checkoutコマンドとは随分意味が違う。 「ちゃんと動くことが分かる」状態に
どうやってもどせばいいんだろうと探している時、コマンドのリストの中の
checkoutコマンドの説明を見ようとは普通思わないんじゃないかな。
788:login:Penguin
10/05/19 00:33:38 rEVii6OV
resetも二つの意味含んでるっぽくてわかりにくいな
unstageと分けてもいいと思う
789:login:Penguin
10/06/01 02:42:24 ke5Egb8T
git checkout を使って ２つ前のコミットまで巻き戻したのですが、
git log すると一番最新のコミットと２番目に新しいコミットが見れなくなってしまいました。
もしかして、checkoutはコミットしたものを取り消してしまう危険なコマンドなんでしょうか？
最新のものに戻したい場合はどうすればいいのでしょう・・
てっきりsubversionのrevertと同じようなものだと思って使ったのですが・・
gitのrevertはリビジョンを戻して新しくコミットしなおす感じのようですが、
最近のコミットを取り消さず、単純にファイルを巻き戻すだけのコマンドはないのでしょうか？
教えていただけると嬉しいです。
790:login:Penguin
10/06/01 03:08:28 ib2iuIgt
>>789
ここまで的確に逆のこと言ってると釣りに見えるな。
git checkout HEAD~2 とかやったのなら、名無しブランチに居るだけだから
元のブランチをcheckoutすれば元どおり。
git revert は指定したコミットを逆パッチしたコミットを作ってくれる。
後戻りはしない。
当たり前にドキュメント読んだほうがいいよ。Subversionとは概念が違う。
URLﾘﾝｸ(progit.org)
URLﾘﾝｸ(www8.atwiki.jp)
791:login:Penguin
10/06/01 06:48:15 nEJNHOMY
タグとブランチで同じ名前のがある時にタグのfoo、ブランチのfoo
という指定はできるのでしょうか。ただfooとだけ指定すると
warning: refname 'foo' is ambiguous.
リポジトリはcvsimportで作ったもので、ファイルによってfooが
ブランチの場合とタグの場合があるためにこういう状態になって
います。
792:789
10/06/01 12:22:08 7rDC0XFu
>>790
レスありがとうございます。
自分がやったのは
git checkcout 862ed98d03863a826dca3246ee61d54264acae57
のような感じなんですが
あげて頂いたドキュメントを見ると、checkoutの説明のところに
「また、これが危険なコマンドであることも知っておかねばなりません。」
のように書かれていました。
やはり最新のコミット自体が消えてしまったように思えるのですが・・
793:login:Penguin
10/06/01 13:52:15 3Zl/kziy
コミットはなかなか消えない。
その下に、
>削除したブランチへのコミットや --amend コミットで上書きされた元のコミットでさえも復旧することができます
って書いてあるよ。
794:login:Penguin
10/06/01 14:35:10 rOsiehIq
>>791
ローカルブランチはheads/foo、タグはtags/fooで明示的に指定できますよ
795:login:Penguin
10/06/01 18:49:32 zlmZbFtl
>>792
reflogというものがあってだな
796:login:Penguin
10/06/01 20:05:14 WTjgN8Mk
>>792
＞ 「また、これが危険なコマンドであることも知っておかねばなりません。」
の部分は作業ディレクトリの情報が消えて、最新のコミットに戻されたって話だよ。
俺はgit以外のvcsをよく知らないけど、
subversionでも、レポジトリと個々人の作業ディレクトリってあるんだよね？
上の話は作業ディレクトリがレポジトリに戻されちゃって、
あなたの作業は消えましたよ、って話だから危険って書いてあるんじゃないのかしら。
797:login:Penguin
10/06/01 20:17:52 WTjgN8Mk
>>789は最新のコミットと２つ前のコミット間の、あるファイルのdiffでも見たいの？
そうなら、
git diff HEAD~2 -- (あるファイル)
っていうのはどう？
どうしてもcheckoutしたいならcheckoutした後、
git diff master.. -- (あるファイル)
でもいい
798:login:Penguin
10/06/01 20:24:44 WTjgN8Mk
>>792
あ、それと言うの忘れてた。
＞ git checkcout 862ed98d03863a826dca3246ee61d54264acae57
なら、>>790も言ってるけど一時的に別のブランチにいるよ。
git branchしてみれば、今までのブランチと別のブランチにいることが分かると思う。
git masterとかやれば元に戻れるんじゃないかな。
元がmasterなのかは知らないけど。
799:792
10/06/02 01:34:42 gi9ro0yc
色々レスありがとうございます。
状況としては、
最近のコミットに
49qayt928t4ht2
と
goghpghr9g9grh
というのがあったとして(文字列は適当です)
49qayt928t4ht2
が最新なのですが、一つ前のgoghpghr9g9grhに戻したいと思い、
git checkout goghpghr9g9grh
としたら、git log しても最新の
49qayt928t4ht2
が表示されなくなり、49qayt928t4ht2のコミットが消えてしまったように見える、
また最新の49qayt928t4ht2に状態を戻したくても、戻した方が分からない、といった感じだったのですが
git reflog と git resetのおかげでなんとかなりました。
勉強になります。ありがとうございました。
800:login:Penguin
10/06/02 05:38:06 tFFCKjtC
>>799
checkout直後なら以前チェックアウトしていたコミットがORIG HEADに格納されてるよ
801:login:Penguin
10/06/02 23:19:00 epvzW2MP
ORIG_HEADってマージのときに使うものかと思ってた
あれ？MERGE_HEADだっけ？
802:login:Penguin
10/06/03 00:57:02 4mfPiwdf
>>792
色々と突っ込みたい所はあるが、とりあえずチュートリアル読めば？
803:login:Penguin
10/06/03 08:35:19 dAM44TeX
>>799
git resetを使う状況じゃない。まずは>>798の内容を理解しよう。
804:login:Penguin
10/06/03 22:34:29 NRpX3vOy
git の branch コマンドは他のVCSみたいな、いわゆる枝(branch)を作るコマンドじゃないことを理解した方がいい。
単に自分のいる点に目印の旗を立ててるだけ。
commitやreset等で自分が動けば旗も移動する。
805:login:Penguin
10/06/03 22:37:18 2hMMbzRW
>>804
これの"create"は「作る」という事ではないのですか？
$ man git-branch
...
NAME
git-branch - List, create, or delete branches
806:login:Penguin
10/06/03 23:35:29 k3O2NdDL
>>805
まあ論理的には「作る」と考えて良いんだけど、、、
内部的には複数のコミットから親として参照されてればそれはブランチと言える
というぐらいで、特にbranchコマンドを使わなくても、ある履歴の途中の位置を
checkoutして何かコミットすれば分岐になるし、commit --amend とかで
やり直ししても以前のコミットと新しいコミットは分岐してる。
ただこの場合古いコミットは一見して行方不明になるけど、branchコマンドは
そこに旗を立てて移動しやすかったり自動でGCされないようにしたりしてる感じ。
reset とかいろいろ試してるうちに内部構造が分かるとそう思うようになったかな。
807:login:Penguin
10/06/04 00:02:52 /Cv0eiGe
各コミットは親を記憶してるから点から親を遡ることで枝を表現できる
ただ子の記憶は無いから自分の子供がどうなったかを辿る簡単な手段は無い
checkout等で移動してコミットが消えてるように見えるのはこの為
808:login:Penguin
10/06/04 06:08:20 PyuP7am3
>>805
自動更新してくれるタグとおもえばよいよ
809:login:Penguin
10/06/05 11:36:02 aEd5JAax
実はCVSでも似たようなことになっているんだけど、
自動GCがないということと、リポジトリの実装がファイル
単位なのでcvs adminコマンドで実現しようとすると1コミット
に関連するファイルに比例して面倒になる、という点が大きく違う。
810:login:Penguin
10/06/05 20:57:10 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 → 成功
811:810
10/06/05 23:35:57 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経由だと最後の方法しかダメ？