09/12/12 15:31:09 1uRf1xZK
>>575,576
日本語で読めるGitの入門書って濱野本、でびあんぐる本、ProGitくらいしかないしなぁ
でびあんぐるのは知らないけどProGit、濱野本の順で読ませるのが分かりやすいんじゃないかな
578:login:Penguin
09/12/12 15:35:54 1uRf1xZK
>>575
Gitが難しいのは、思想や観念を理解するのが難しいわけじゃなくて
コマンド/オプションが多すぎる、同じコマンドで2種類以上の役割を持たせてる
あたりが敷居を高くしてる気がする
579:login:Penguin
09/12/12 18:45:28 7I0ALriM
>>578
いや、コマンドの数が多いのは確かだけど、普段使うものは数えるほどしか無いよ。
それに全コマンド一覧なんて初心者に見せるか？ 下位レベルコマンドは知る必要ないし。
もっとも障壁が高いのはGitの本質を知る事だと思う。特にsvnをやってた人は
「Gitで何が出来るのか」ではなく「svnでやっていたことをGitでやろう」とするので
自分がやっていることがほんとうは何を意味するのかよく分からないまま使うことになり、
「使いづれー」ってなる気がする。
頭を切り替えてチュートリアルを実践するだけで、けっこう分かると思うんだけどな。
>>577
最近初心者向けにGitのことブログで書いてる人も多いね。俺は純正チュートリアルでも
けっこういけると思うんだけどね。最初は会社の同僚からGit教えてもらったんだけど、
これは麻薬ツールの典型なんだが、会得してしまった人は会得してない人に教えるのが
上手くできないんだよね。viとかemacsとか、そう簡単に教えられるものじゃないみたいに。
だから結局は全て自分でチュートリアルやって覚えたけど、最初はどうしてもsvnとかに
なぞらえてしまって、イライラしたな。
580:login:Penguin
09/12/12 19:41:26 91i8JXzY
>>578
resetはreset(巻き戻し)とunstage(indexからの削除)に分けるべきだよな
他には何があるっけ？
581:login:Penguin
09/12/13 04:59:08 XTGOd8wr
>>579
Webなんかでも、svnのこのコマンドに相当するgitのコマンドは何？って質問が
結構あるしやっぱり本質は理解されてないかんじですね
indexも存在意義がわかれば非常に便利なんだけど。
Winの話題で申し訳ないけれど、TortoiseGitなんかもindexの存在を隠して
ワークツリーから直接コミットするような作りになってるし
＞これは麻薬ツールの典型なんだが、会得してしまった人は会得してない人に教えるのが
たしかにそうですねｗ
>>580
よく使うコマンドだと
checkout ブランチ名（ブランチ切り替え）
checkout -- ファイル名（ファイル取り出し）
reset HEAD^（コミット取り消し）
reset ファイル名（ファイルアンステージ）
reset --hard（ワークツリーの修正取り消し）
582:login:Penguin
09/12/13 12:05:06 eLNfVime
言葉で伝えるのは難しくて
チュートリアルをいじって自分の頭の中に動作イメージを作るか
よくできた紙芝居を見せてもらうかしないと
「わかった」とはならなよね。
583:login:Penguin
09/12/13 21:39:57 MfgUdwK5
>>580-581
まあでも「alias書けば?」で終わるレベルじゃん
584:login:Penguin
09/12/13 22:56:38 hWQ7uDdJ
だよね
585:login:Penguin
09/12/13 23:48:27 yRHWt0hz
打つのがめんどいって話じゃなくて分かりづらいって話では？
586:login:Penguin
09/12/14 00:06:09 iC7LD6wI
aliasには「分かりやすい名前をつける」という機能もあるんだけど
587:login:Penguin
09/12/14 00:12:42 1YNrTAVE
一度やりたいことをしてくれるコマンドを知れば別名も
付けられるんだけどねー。
分かるまでがたいへん。
588:login:Penguin
09/12/14 00:21:12 MiMO4S1u
そのaliasを設定するためにはコマンドの使い方知ってなければ
ならないが、話の論点わかってますか？
589:login:Penguin
09/12/14 00:50:41 uqSDssQD
aliasでこんなんやっちゃう人もいるみたい
URLﾘﾝｸ(github.com)
590:login:Penguin
09/12/14 20:21:03 9KU3MLe4
俺はrefspecの表し方がよく分からない。
文脈で書き方が
$ git push repository branch
だったり
$ git merge repository/branch
だったりするところとか。理解しきれてないからなんだろうけど。
591:login:Penguin
09/12/14 22:02:14 iC7LD6wI
>>588
そしてある程度分かってきたら、よほど長くない限りalias使わなく
てもよくなるんだけど、誰かが作ってくれたalias集をwebから
持ってきて、... なんて方法も今はあるからね。
592:login:Penguin
09/12/15 00:21:21 uU/CeyJd
リモートブランチの扱いが俺も最初はとまどったけど
省略形じゃなくてフルで記述するコマンド体系を覚えてから
省略形を使うようにしたら、すんなり理解できた
$ git push repository branch
は
実は
$ git push repository branch:branch
の省略形で、手元のbranchからrepositoryのbranchへ対してpushしなさいという意味
一方mergeのorigin/masterなどは、具体的なコミットを指しているので
リポジトリ名/ブランチ名となる
593:login:Penguin
09/12/15 04:59:39 pR/bRTj/
>>592
もう忘れてたけど確かに俺もそうだわ。
pushはフル書式で理解するまではかなり自信なさげに使ってた。
594:login:Penguin
09/12/24 15:20:36 v3JWri2J
1.6.6 released
595:login:Penguin
09/12/25 21:55:28 lY3loZi6
stashとresetに頼りまくってる自分の使い方は邪道なんじゃないかと
気になるんだが、indexとかうまく使えば減るだろうか
596:login:Penguin
09/12/26 00:20:32 EUZh5OCV
>>595
運用上不都合がなければいいんじゃない?
597:login:Penguin
09/12/26 06:40:51 SkSud091
>>595
reset、rebase、resetに頼りまくれるようになってはじめて、一人前のGit使いだと思う。
commitとmergeだけじゃ今までのVCSと変わらないじゃないか。
598:login:Penguin
09/12/26 06:42:53 SkSud091
reset、rebase、resetってなんだよorz
reset、rebase、stashのつもりだった。。。
あとrebase --onto、rerereなんか使うとさらに先にいける。
599:login:Penguin
09/12/26 10:39:25 AQehkmKr
おーでかーけでーすかー
600:login:Penguin
09/12/26 12:12:59 Z6Z05dDL
今だにpush,pull,rebaseの使い分けがわかんないんだよな。
普段git svnでやりとりしてるとrebaseだけで事足りるというだけなのか
601:login:Penguin
09/12/29 01:24:35 AAGVKxmF
そりゃgit svnではpush, pullは使いようがないというか、使ったらぶっ壊れるんじゃ。
602:login:Penguin
09/12/29 14:12:54 utuwRMGk
他にもgit svnを使っているメンバーがいた場合、
そいつとは、pushやpullができるという
603:login:Penguin
09/12/29 18:19:26 erZVRnS3
>>602
でも結局いつかgit svn rebaseするから、ID全部変わるしマージコミット入れられないしで
うぼわーマジsvnやめようぜクソがぁ！
ってなる。
604:login:Penguin
09/12/30 07:38:54 kfBW1mPl
しかしsvnに入れた分はちゃんとIDそろうのはすげーと思ったな。
605:login:Penguin
10/01/08 12:31:36 S57JTlxp
オリジナルの拡張子を持ったファイルをコミットすると、rawファイルとして認識されるみたいですが、
textファイルだとgitに教える方法はありませんでしょうか？
606:login:Penguin
10/01/09 10:57:40 3So5fkbw
>605
gitattributes で crlf と diff をセットだと思う。
607:login:Penguin
10/01/12 19:43:07 2XlpNrfT
githubみたいに、git archiveで生成するアーカイブに
コミット名を入れたいのですが、みなさんはどうやって取得していますか？
知りたいコミットがHEADとした場合、bashでは
VER=`cat ".git/\`cut -d \ -f 2 .git/HEAD\`"`
でコミット名が取得されるのですが、
Makefile内だとうまくエスケープ？されなくて困っています。
他の方法があればそちらで試してみたいと考えています。
ちなみに、Makefile内では
@VER=$(shell cut -d \ -f 2 .git/HEAD)
@VER=$(shell cat .git/$(VER))
echo $(VER)
としているのですが、変数VERが空になってしまいます。
608:login:Penguin
10/01/12 23:43:38 914bGyNn
git describe --always
609:login:Penguin
10/01/13 05:50:58 +l7m8J7G
git rev-parse HEAD
610:login:Penguin
10/01/13 09:58:54 /kr/i6EO
github は、タグからアーカイブを生成する場合、アーカイブのファイル名にタグ名を含めてほしい。
611:login:Penguin
10/01/18 10:24:04 xAKlwsjN
example.log っていうファイルがあって
このファイル自体はpushされていて、でも今後の変更分についてはpushしたくないってとき、どーするのが正解？
git rm --cached して版管理自体をやめるわけにはいかないんだけど
612:login:Penguin
10/01/18 11:48:43 9pALEWP2
ignore すれば？
613:login:Penguin
10/01/18 11:58:05 xAKlwsjN
>>612
すでに版管理されてるからmodified filesとしてあがってきちゃう
commit対象としてのみ無視したいんだけど、ignoreできるの？
614:login:Penguin
10/01/18 20:36:24 KAj8+0o6
>>611
ローカルリポジトリでバージョン管理するのを止めれないなら
ignoreできないから、簡単な方法はないでしょう。
push用のブランチを作り、手でrebaseしてそのファイルへの修正が
入らないようにしてからpushするとかしか思いつかないけど。
615:login:Penguin
10/01/18 20:43:21 2FuAr7Gb
push 用の branch とローカルでの example.log の変更を commit する branch とを作ればいいんじゃないかな。
616:login:Penguin
10/02/04 11:09:26 5W3FJugT
CVSやSVNは集中型、gitは分散型 とあるんだけど
何が集中したり分散したりしてるの？
617:login:Penguin
10/02/04 11:11:53 CYNiw1E3
リポジトリ(履歴データを持っている場所)が1つか、複数か。
618:login:Penguin
10/02/04 13:34:55 YQOQkcZC
集中型は権力も集中しがちになる（コミット権がうんたら）
619:login:Penguin
10/02/04 14:30:46 5W3FJugT
じゃあgitはオープンソースに適してるんですね。
仕事用で使いたくて、なるべく権力を集中させたいので
gitは見送ります。ありがとうございました。
620:login:Penguin
10/02/04 17:54:59 5NWhCwR0
ワークフローは運用次第ってだけの話だが。
URLﾘﾝｸ(progit.org)
URLﾘﾝｸ(github.com)
621:login:Penguin
10/02/04 19:37:14 YQOQkcZC
分散型に出来て集中型に出来ないことは無いんじゃない？
622:login:Penguin
10/02/04 19:39:44 YQOQkcZC
あれ逆か、集中型で可能なことは分散型で出来る。
623:login:Penguin
10/02/04 19:55:52 gmC/Yryo
>>619
要は、運用次第で権力集中可能
例えば、マスターリポジトリの更新権限を限定するとか（つ～か普通そうするんじゃ…)
624:login:Penguin
10/02/04 20:47:50 JYXesGU0
>>622
オフラインでのコミットとか無理じゃね？
ローカルにリポジトリあれば別だけど自分以外ができないからあれだし
625:login:Penguin
10/02/04 21:36:49 G2p82aGi
あと、うっかり変なcommitをしてしまったとき、gitならpushしない限り大丈夫だが、
集中型だとお説教タイムになってしまう悪寒
626:login:Penguin
10/02/05 00:04:47 +YPRuxoa
>>625
巻き戻せばいいだけでは。
627:login:Penguin
10/02/05 01:55:01 CLmEj5oN
>>626
普通巻き戻しは特権がいるんじゃない。 で、特権のある人に
お説教されるとw
628:login:Penguin
10/02/06 00:46:55 44qJRz29
お説教なの? ニヤニヤされるんじゃなく?
629:login:Penguin
10/02/09 20:22:37 RAlUQWhi
せんせーきほんてきなしつもーん
ターミナルが A と B の 2個あったとして、
A で git checkout one したあと
B の Emacs でたくさん git 対象ファイルを開いて、そのまま、
A で git checkout two するとします
Emacs で開いてるバッファ内容ってやっぱり one のままだよね？
バッファを編集して保存したら one のファイル内容が two のファイルに上書きされて「危険」だよね？
A でブランチを切り替えるたびに Emacs のバッファは全部閉じて再度開きなおさないといけないよね理屈上
630:login:Penguin
10/02/09 20:36:57 b7GskCpL
emacs使いじゃないから知らないが、バッファ読み込み後にファイルが更新されてるのを
警告もなしにそのまま上書きしちゃうのか？
631:login:Penguin
10/02/09 20:39:16 acViODVs
ﾆﾔﾆﾔ
632:login:Penguin
10/02/09 20:39:37 nKVKxkV8
ちゃんと警告してくれますよ。
633:login:Penguin
10/02/09 20:47:12 9V49chdu
screen と emacsclient使え。
634:login:Penguin
10/02/10 09:43:04 QkCzSUH3
Emacsの revert-buffer を使えばバッファを再読み込みしてくれるけど……
635:login:Penguin
10/02/10 10:00:40 0TBtUf8g
>>629
危険ていうか、それはgitじゃなくても他の端末から同じファイルを編集したら同じことになるでしょ。
俺はvimだけど、ブランチ切り替えもそうだけど、git stash -> git svn dcommit -> git stash pop
ってやった後に保存しようして、警告が出るな。
このパターンだと十中八九ファイルの内容は変わってないんだけど、念のため確認するようにしてる。
636:login:Penguin
10/02/10 15:21:40 M9UhD/wS
git-mode上でブランチ切り替えたら再読み込みしてくれたりしないかな
ようはEmacsがブランチ変更を検知しないことが問題なんだよね
上書き警告だって本質的な対策じゃない
ブランチが変更されたんだから、編集したいのはそのブランチのファイルのはず
637:login:Penguin
10/02/10 15:26:10 3rYFILyb
Emacsの普通の設定ならタイムスタンプが変わってたらrevertするか聞いてくるだろ
638:login:Penguin
10/02/10 15:31:20 M9UhD/wS
>>637
それがめんどくへえという話なのでは…
編集中のバッファでなければこっそり開きなおしてくれてるくらいのサービス精神がないと
不況下の日本ではEmacsは生き残れないぞたぶん
639:login:Penguin
10/02/10 15:33:25 uKVeMcIn
>>638
そうしたいならそうすればいいじゃん
640:login:Penguin
10/02/10 15:43:03 9JULZJQU
git はメンテしてる Junio Hamano 氏がとんでもないナンパ野郎だと知って以来、
極力避けるようにしてる。濱野氏がメンテから降りたらもっと使ってもいいかな。
641:login:Penguin
10/02/10 16:33:53 wST9AMIH
ふーん
642:login:Penguin
10/02/11 11:44:58 yw+dRYs8
>>640
どのへんがナンパ野郎なのか教えて
643:login:Penguin
10/02/11 12:45:14 XV6xszzu
濱野氏は、美人研究者のブログで、その人が git 好きなのをネタにして、
「今度 git の講演に日本に行くから、その時に二人でデートしようぜ」
と本気でナンパしていたと聞いている。
644:login:Penguin
10/02/11 15:02:11 nZMD/n4Y
べつにgitをユーザが増えようと減ろうとJunioのナンパに貢献する
ことはないと思うけど、それ以前に共通の趣味をネタに口説くこと
がどうまずいのかも不明。
645:login:Penguin
10/02/11 15:10:50 yJW9hFuf
女を捨てまくってるとかならともかく、アプローチしてるだけでそこまで嫌悪する必要ないだろ
646:login:Penguin
10/02/11 15:55:14 WaojUPKf
>>643
糞ワロタwww
ブログでかよ？
他に読んでる奴等もいるだろうし、
さすがにそれはねーわなw
647:login:Penguin
10/02/11 17:30:48 aEGTGT/7
gitに使う価値があるかどうかは、
メンテナ氏の女性へのアプローチ法とは関係がない
648:login:Penguin
10/02/11 19:24:12 oAJQYaS+
どこのblogかkwsk
649:login:Penguin
10/02/11 20:12:33 jeJxZddW
嫌儲の男女バージョンみたいな感じだな
650:login:Penguin
10/02/11 22:27:09 71QNNVeu
>>638
auro-revert-bufferじゃだめなのか？
651:login:Penguin
10/02/12 01:58:47 hFHmJq9f
ソースコードを本番にデプロイする時についてなのですが、
前回デプロイ時のソースとの差分だけ抽出して、そのファイルだけ本番にデプロイできるようにしたいと考えています。
今レポジトリにコミットしたリビジョンと、前回デプロイ前のコミット時のリビジョンの差分を
抽出することができればと思うのですが、それ用のコマンドってgitにあるでしょうか？？
教えていただけると幸いです。
652:651
10/02/12 02:00:25 hFHmJq9f
すいません、言葉足らずでした。
>>今レポジトリにコミットしたリビジョンと、
>>前回デプロイ前のコミット時のリビジョンの差分を
>>抽出することができればと思うのですが、
更新のあったファイルの「ファイル名」だけ、gitのコマンドで抽出できないか、という意味です。
653:login:Penguin
10/02/12 08:54:33 hx+CbuVO
>651
どーやってデプロイしてるのか教えれ。
654:login:Penguin
10/02/12 11:50:19 StLEjzjs
>>652
git diff --name-onlyとか、どう？
655:login:Penguin
10/02/12 14:33:42 MaWIE5lB
>>651
普通にgit pullしたら早いと思うんだけどな。
rsyncするよりも手軽だし。
656:651
10/02/12 15:29:51 hFHmJq9f
レスありがとうございますm(_ _)m
>>653
ftpかsftpでデプロイしようと思っています。
本番環境はさくらインターネットの供用サーバです。
>>654
やってみました。
これって、コミットする前の、さらにステージする前の差分ファイルを抽出するんですね。
git diff --cached --name-only って試してみたらステージ後の差分ファイル一覧も出力出来ました。
やろうとしていることは大体こんな感じなのですが、
２つ前のコミットと１つ前のコミットの間で更新されたファイル一覧の出力ってのはできないでしょうか？？
>>655
なるほど、本番環境に入ってpullするんですね。
仕事では本番サーバも自分で用意してgit環境も構築してたのですが、これってやったことありませんでした。(普通にsftpとかrsyncで・・)
ただ今回の場合、デプロイ先がさくらインターネットの共有サーバなので、git環境を構築出来ないと思うんですよね。
なので普通にftpとかsftpでアップしようと思っています。
ちなみに、本番環境でgit pull する方法で、本番ウェブサーバが複数ある場合は、
それぞれにログインしてウェブサーバ毎にgit pullする感じですか？
657:login:Penguin
10/02/12 15:54:21 MaWIE5lB
>>656
＞ちなみに、本番環境でgit pull する方法で、本番ウェブサーバが複数ある場合は、
＞それぞれにログインしてウェブサーバ毎にgit pullする感じですか？
どれぐらい気をつかってやるかにもよるんじゃないか。
静的コンテンツをただ更新するだけならrsyncとかgit pull/pushとかをスケジューリングで
自動でやらせてもいいかもしれないけど、warなんかだとそうもいかないだろうから
リリース毎にウェブサーバ切り替えながら慎重にやるんじゃない？
てきとうにググったら、さくらのレン鯖にGit入れてる人けっこう居るみたいだよ
URLﾘﾝｸ(www.google.co.jp)
俺もさくらのやつあるんだよね。今度やってみようかな。
658:651
10/02/12 21:58:43 hFHmJq9f
>>657
レスどもです。
そーか、スタンダードプランならsshとか使えるし、gitのインストールもできるんですね。
早速
URLﾘﾝｸ(d.hatena.ne.jp)
これみてやってみたんですが、
git push --all
のところで
Permission denied (publickey,password).
fatal: The remote end hung up unexpectedly
っていわれてしまいました。
さくらのスタンーダードプランのssh接続って試してみたら
鍵認証なしの単純なパスワード認証みたいなんですけど、
git push の時のssh接続では鍵が探されてる？気がします。
上の記事書いた人はなんでうまくいったのか・・
git://プロトコルにするとポートが開いてないみたいでダメです。思案中・・
659:login:Penguin
10/02/12 22:57:55 meESnmZa
>>658
単に向こうの~/.sshやauthorized_keysのパーミションの
問題とかではなく?
660:651
10/02/13 00:05:44 IZfm7XrQ
>>659
いま一応確認してみましたが、~/.ssh のパーミッションは755で、authorized_keysはありませんでした。
普通にsshでログインしようとしたら鍵認証じゃなくてパスワード認証になるので
authorized_keysはないのは問題ないと思うんですが
gitでssh接続しようとするとなぜか鍵認証にしようとします・・なぜだー。
661:login:Penguin
10/02/13 02:02:29 52GS5xAq
man co
662:login:Penguin
10/02/13 09:09:31 mH7bnksn
>>656
> ２つ前のコミットと１つ前のコミットの間で更新されたファイル一覧の出力ってのはできないでしょうか？？
git diff --name-only HEAD^^ HEAD^
それぞれのcommitのSHA-1値を与えてもOK。詳細は git diff --help してみるのがよいかと。
663:login:Penguin
10/02/13 11:21:11 tHnX+oRf
1.7.0 ｷﾀ━━(ﾟ∀ﾟ)━━!!
URLﾘﾝｸ(article.gmane.org)
664:login:Penguin
10/02/13 11:53:52 06CKMljI
あれなんか空のディレクトリいつのまにかサポートされてる？
665:login:Penguin
10/02/13 16:21:28 3p2VcGOY
>>664
mjd??
666:login:Penguin
10/02/15 11:27:21 v96hRl2p
>>647
reiserfsを使っている俺には死角はなかった。
667:login:Penguin
10/02/15 22:23:02 Ap57uWpz
URLﾘﾝｸ(progit.org)
お、ちゃんと日本語に戻ったな。
ちょっと前まで何語かよくわからんのにすり変わっていて笑ったんだけど。
668:login:Penguin
10/02/18 22:09:12 yUl4nZSS
>>663
repo.or.czのミラーって更新遅いんだな...
669:login:Penguin
10/02/23 21:07:12 hI3BlWsm
ようやく、なんとか git add -p / git commit -v
に慣れてきた感じ。
git add も当たり前だがわかっててやらないと(?_?)な
状態にすぐなる。git add -u とか
git commit -v -m "hoge" huga.txt
とか、けつまずいた。git reset HEAD^ に何度も助けられたぜ。
670:login:Penguin
10/02/23 23:41:35 ZVOkCMZj
俺も最近なれてきたけど
少し前まではgit pushした後、
別の日にgit commit --amendから初めて
git pushして、パニクってたものです・・・
671:login:Penguin
10/02/24 16:05:44 wK5Zb8Pm
サブモジュールとサブツリーってどう違うのかよくわからん。
複数プロジェクトを1レポジトリでまとめたいんだけど
どうすりゃいいの？
672:login:Penguin
10/03/02 23:16:21 jWjxjdrz
復活カキコ
673:login:Penguin
10/03/05 07:39:15 nZaP2lzx
みなさん、もう$Id$とか使ってないですか？
674:login:Penguin
10/03/05 08:23:57 T3bjYh1e
それgitで使えるの？
blameとか見ればいいんだし使わないよ
675:login:Penguin
10/03/05 16:26:48 HZ7fJgn/
最近TortoiseGitが1.3.6にヴァージョンアップしたもようですが
1.3.2対応の日本語化パッチが使えなくて困ってます。。
是非1.3.2にヴァージョンダウンさせたいんですが本家のぞいても前ヴァージョンが無いんですよね・・・
どこかに1.3.2転がってませんかね？
676:login:Penguin
10/03/05 16:38:07 Cxd0LGFJ
>>675
開発元サイトにあるぢゃん
URLﾘﾝｸ(code.google.com)
677:login:Penguin
10/03/05 18:22:52 vhUyLNw1
msysgitの方も最新版出ないかなぁ
678:login:Penguin
10/03/05 23:40:59 nZaP2lzx
>>674
attributesファイルに * ident って書けばできるんですけど、
日付とかではなく、コミット名(ハッシュ値)になるみたいだし、
checkoutした時しか置換されないようです。
今までSubversionとかで$Id$使ってたソースをGitに移した場合、
全ファイルのこの部分は、この先どうしていけばいいんだろう？と思いました。
679:login:Penguin
10/03/06 00:08:17 OxENSWUe
正直RCSキーワードのためにしょうもない(前処理で$Id$に戻すとか)
コミットスクリプトが必要なのが無駄。気にしないようにするか、
日付やリビジョンを含まない形に全置換しとくかすればいいと思う。
680:login:Penguin
10/03/06 00:09:03 OxENSWUe
CVSだとそうなんだけど、svnだとスクリプトは不要なのかな?
681:login:Penguin
10/03/06 00:37:19 5+PCqCSd
TortoiseGIT より期待してる git extensions が backend として cygwin 1.7 も
使えるようになり、UTF-8化が可能になるかと期待したが、cygwin の git process
呼び出しで、.netが勝手にlocal cp(日本版ならcp932)に変換しやがる。
stdoutとstderrは、encodeを変えるオプションがあるし、実際それを使って、utf8
文字列として読み込んでくれるんだが、何故かstdinには無い。
processの引数と、stdinをutf8で渡せれば何とかなりそうなんだが・・・
682:login:Penguin
10/03/10 06:42:35 KudZTj20
git.hogehoge.comというＶｉｒｔｕａｌｈｏｓｔで公開した場合
アパッチの設定ってどういう記述すればいいんでしょうか？
<VirtualHost *:80>
ServerName git.55train.info
CustomLog /var/log/apache2/git/access.log combined
ErrorLog /var/log/apache2/git/error.log
DocumentRoot /sites/git/www/html/
<Directory /sites/git/www/html/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Alias /prj "/var/git/projects"
<Location /prj >
DAV on
AllowOverride None
AuthUserFile /var/git/projects/.davpasswd
AuthGroupFile /dev/null
AuthName "dav user"
AuthType Basic
Options Indexes -FollowSymLinks
</Location>
</VirtualHost>
っていう記述だと、中においてるスクリプトファイルが反応して.gitフォルダにアクセス出来ないようなんですが・・・
683:login:Penguin
10/03/10 08:58:20 Ut6hXZPm
ｽﾚﾘﾝｸ(saku2ch板)
684:login:Penguin
10/03/10 10:08:15 ZHIpTB9l
さてさて
やれやれ
685:login:Penguin
10/03/10 11:22:43 rvbZnmFs
>>682
「スクリプトファイルが反応して」ってどういうこと?
686:login:Penguin
10/03/10 11:41:55 VG72PX0T
お騒がせしてすいません。
特に何も入って無いサーバーなので、特に問題は無いと思うんですが、
念のためapache等は落としておきます。
徹夜明けの寝ぼけた頭で投稿したのがまずかったようです。
>>685
普通にapacheで動作するスクリプトファイルを置いていたので、
git clone 'http://～'だと反応したんだと思います。
"ForceType text/plain"かchmodで対応してみようと思います。
すいませんでした。
687:login:Penguin
10/03/10 11:59:59 4WH27GGD
セキュリティが不安なら、そもそも公開すんなよ
688:login:Penguin
10/03/10 13:05:13 oeQspfUo
優しくしてやれよ！
689:login:Penguin
10/03/10 21:35:44 HKIKwOTL
削除要請板からきますた
なんか色々大変ですね
690:login:Penguin
10/03/10 22:16:33 DRNWG7Oz
名前まで出してしまいましたね。
691:login:Penguin
10/03/10 22:17:57 b2Fg0cB+
わざわざ削除依頼なんてしなけりゃスルーされたよね
692:login:Penguin
10/03/10 22:43:37 rtnf98lv
どうかな
693:login:Penguin
10/03/11 05:05:22 vWTSpXf4
俺は気づかなかった。見た瞬間とりあえずくだ質問行けよとか思った。
694:login:Penguin
10/03/11 07:17:44 a4pU/TF4
>>686
>git clone 'http://～'だと反応したんだと思います。
だから反応ってどういうことだよ池沼が
695:login:Penguin
10/03/12 00:35:01 g58g7Khc
まあ落ち着け。
とりあえず俺はgitどころか
カーネルのアップグレードに失敗したらしく
かなり焦ってる
バックアップの必要性は必要になってから気づくんだ
696:login:Penguin
10/03/14 23:02:16 74SKWdA2
コミットの指定で使う ~ と ^ の違いがよく分からないんだけど、
例えば、HEAD~2 とか HEAD^2ってどう使い分けたらいいの？
697:login:Penguin
10/03/15 00:13:16 9vDzc51S
縦軸と横軸だ
698:login:Penguin
10/03/15 00:17:27 9vDzc51S
c~3-c~2-c1~-c(HEAD)
c^2 」
c^3 」
c~3-c~2-c1^-c(HEAD)
c^2 」
c^3 」
699:login:Penguin
10/03/15 00:18:53 9vDzc51S
^複数の親と、~複数の世代の違い
700:login:Penguin
10/03/15 00:20:25 vdbEsin0
その２つは異なるものだよ
~nはn個前の親を表していて
^nは1つ上のレベルのn個目の親を表す
D-E
/ \
A-B-C-F
FがHEADの時にAはHEAD~3
CかEがHEAD^1、HEAD^2。
701:login:Penguin
10/03/15 00:58:04 INJko3Py
ありがとうございます。やっと分かりました。
^はマージによってコミットに複数の親がある時、それぞれの親を指定できるんですね。
すっきりしました！
702:login:Penguin
10/03/15 03:38:25 5FqVvyVi
すっきりしない
703:login:Penguin
10/03/16 09:03:16 5gE8Vm9w
subversion からcloneしたリポジトリで git branch -r すると@12とか
複数のバージョン？見たいなのが出てくるんですが、これはなんですか？
704:login:Penguin
10/03/16 18:59:10 I38d2Qfd
gitは基本的に戻ることはないんだねぇ、
恥ずかしい失敗したらコマンド使ってコミット無かったことにするけど
705:login:Penguin
10/03/16 19:22:14 UUVEpT2o
基本的に戻ることがあるようにしてるVCSなんてあるの？
706:login:Penguin
10/03/17 21:14:49 ZS5QfrTO
git reset でいくらでも戻れるぜ。ただ、それよりも
1. 作業用ブランチでは気にせず commit/revertしまくる
2. 作業終わったら作業用ブランチの根元から新しくブランチを切る
3. cherry-pick とかで綺麗な履歴を合成
4. 作業用と新ブランチのdiffに差がないことを確認
5. 作業用ブランチはまるごとさようなら
がオススメ。1commit に複数の仕事を含めないようにしないと後で
カオスになるけど。
707:login:Penguin
10/03/18 00:36:24 dr1HU4dM
>>706
お前は俺かｗ
そんな神経質なことやってるのは俺ぐらいなもんだろうと思ってたぜ。
ただ、履歴が綺麗だと気分良いけど、仕事ではそれなりで我慢するようにしようと心がけてる。
あとそのやり方やってると、diffで何も出ないんだからgit branch -D でさよならで
良いはずなんだけど、どうも念のために残しておきたくなっちゃうんだよな。。。
だからtopic_bk1 topic_bk2 ... とかいう感じで、ゴミブランチがたくさん残ってしまう。
708:login:Penguin
10/03/18 00:48:06 wZ6/zNxh
それでいいんじゃね？ 増井俊之のいう富豪的プログラミングの一例として
テキストデータなんてどうがんばってもHDD1台分も書き溜めることはできないんだから
いくらでも残しておけばいいんだと思うよ
709:login:Penguin
10/03/18 01:28:19 dr1HU4dM
でもあれだぜ、git branchが一画面分超えちゃうようになるとちょっと考えちゃうぜ。
デフォで git branch | grep hogehoge しないと使ってられない。
ってまあ、そうなる前に整理しろって話なんだけどね。。。
手動でgcした時だけ消える（消えなくてもいいけど）普通にはリストに出てこないtrashes的な属性が
ブランチに付けられたらいいなと思った。けどgit-branchはスクリプトじゃなくてC実装だったので寝る。
710:login:Penguin
10/03/18 02:50:25 6BBqQXR0
あー、なるほど、作業用ブランチでrevert使ってなかったわ
711:login:Penguin
10/03/18 23:14:55 dr1HU4dM
1.7はこんなん変わってるから注意、みたいなの教えて欲しい
712:login:Penguin
10/03/19 11:41:12 r52T5pgD
git tag は-lでタグ指定して見られるのに、git branchは一覧しか見られないのはどうしてなぜなんだぜ
713:login:Penguin
10/03/19 19:37:38 NIuQLQlK
>>712
tagは、大抵付けっぱなしだけど、branchはmerge済みになれば(俺は)消しちゃうから
選ばなくても、そんなに沢山出てこないんじゃないかな？
714:login:Penguin
10/03/19 20:23:13 sUcT09Pz
>>709
ゴミブランチが多すぎてうざくなったら、clone して
別リポジトリでとっておけばいいんじゃね？
また必要になったら pull すりゃいいだろうし。
715:login:Penguin
10/03/19 20:35:42 sUcT09Pz
ちなみに >>706 の 3 は commit が多い場合 cherry-pick じゃなく
て format-patch でファイルに落としてから選別、 git am で一気
に進めると楽。ただし、commit log の1行目に適切なサマリを書い
てないと選別作業がカオスにw
716:login:Penguin
10/03/19 20:55:59 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. 作業用ブランチはまるごとさようなら
とかでサクッと分割できる。
717:login:Penguin
10/03/19 21:01:59 sUcT09Pz
ついでにもういっこ。
この手の作業するのに gitk --all は欠かせない。各ブランチHEAD、
ブランチ間のつながり等が一目瞭然なのでイメージをつかみやすい。
718:login:Penguin
10/03/19 21:55:21 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 とかつけてね。
ということらしい。
719:login:Penguin
10/03/20 01:01:58 250FD1S2
>>718
なるほど。すません、英語読むの面倒くさがって。
git1.7は一部後方互換性なし、って見出しでよく言われてるけど、普通に使ってるぶんには
まったく問題なさそうだね。チェックアウト中のブランチにpushしたらデフォで拒否ってのは
安全でとても良いと思う。
>>714
なるほど、そうしてみるわ。ゴミ置き場リポジトリね。最近cloneはハードリンクがデフォになったようなので
そこは注意だけれども、、、
>>717
そうそう、gitk以上に見やすいのは知らない。つってもマージ激しくない時はshow-branchでどうにかなるけど。
>>716
それって最終的にマージして終了？ まっすぐにして残そうとはしないの？
720:login:Penguin
10/03/20 01:24:01 Y/nTXIhi
GUIならgitkかqgitかな、と思ってる
721:login:Penguin
10/03/20 02:00:55 VyCYaEo0
>>719
> >>716
> それって最終的にマージして終了？ まっすぐにして残そうとはしないの？
おっと、topicA, B ともに、まだ作業中のイメージでした。
作業が完了してるなら統合用ブランチにマージして終了ですな。
722:login:Penguin
10/03/20 04:50:50 lzllMVc3
URLﾘﾝｸ(sourceforge.net)
723:login:Penguin
10/03/20 22:08:34 8SKMhpSs
ずうううううううっと思ってたんだけど、コミットログ書くときに今回どこを変更したかってふつう覚えてなくね
コミットログに書いておくべきであるような変更をぽろっと書き損ねるとかありそうでヤじゃね
それとも忘れないような小さなカタマリで鬱陶しいほど細かく作業単位でコミットするもんなの？
それともみんなコミットログ書くときには別窓で git diff とかの結果眺めつつ書いてるの？
724:login:Penguin
10/03/20 23:00:31 CNETOYMb
>>723
＞コミットログ書くときに今回どこを変更したかってふつう覚えてなくね
git commit -v 使うといいよ。
どこを変更したじゃなくて、なんで変更したのかを書くといいよ。
git diff使えば変更点なんかすぐ分かるんだから。
＞小さなカタマリで鬱陶しいほど細かく作業単位でコミットするもんなの？
鬱陶しいかはしらんけど、俺は結構細かくつけてるけど。
一気に変更した後、git add -p使ってコミット自体は細かくしてる。
この時に、意味的に1種類のコミットにするようにして、
すぐgit commitしちゃうから-vオプションつけなくても、
コミット内容は頭に入ってるかな。
725:login:Penguin
10/03/21 00:21:34 EU6VkwB8
>>723
何か目的があってソースいじってるんだから、その目的を書けばいいんじゃないかね。
逆に言うとどんだけデカい差分になってもいいから、別の目的の差分は入れるべきじゃないと思う。
例えば、機能追加なのにちゃっかりバグフィックスも混ざってるとか。
726:login:Penguin
10/03/21 09:08:50 GHhv3uqI
>>723
gitx ではとりあえずコミットログを書きながら
コミットするファイルの一覧から diff 表示させられるから
忘れてても全然 OK
727:login:Penguin
10/03/25 08:29:22 ACJlY4U7
muzu-
728:login:Penguin
10/04/01 15:28:34 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には対応しているはずなんですが。
729:login:Penguin
10/04/01 15:29:18 M9uKaIit
数値でっていうかバイナリなのか。gitはファイル名をバイナリで扱うんだっけ・・・
730:728
10/04/01 15:41:21 M9uKaIit
gitで日本語ファイル名を無理やり通した - きみのハートを8ビットキャスト
URLﾘﾝｸ(d.hatena.ne.jp)
こういうのって公式に取り込んでもらう方法ってないもんでしょうか？
731:login:Penguin
10/04/01 15:45:28 8lE6TdJZ
>>729
core.quotepath = false
でいけます。
732:login:Penguin
10/04/01 16:38:48 ivXW99qP
どこかに覗いたら勉強になるようなＯＳＳのＧｉｔレポジトリないでしょうかね？
733:login:Penguin
10/04/01 22:37:08 fogg5tiY
gitだと、公開リポジトリは綺麗な歴史になるようにしてる
はずだけど、どういう勉強がしたいの? 自分で実験してみる
以上に勉強にはならないとおもうけど。
cloneしてから、一個一個コマンドを試していけば
いいんじゃないの?なんかダメなの?
734:728
10/04/02 03:19:32 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です
735:login:Penguin
10/04/04 12:24:16 N7boF9sc
>>732
ｽﾚ違い
736:login:Penguin
10/04/11 23:37:35 gnsZLsDv
document.createElementで作ったinputをｊQueryで追加したんですが、
そのInputの入力Boxで文字列が選択できません。
これはなぜ？
737:login:Penguin
10/04/12 01:08:08 zlVRCvUq
どこの誤爆だ。
738:login:Penguin
10/04/12 05:36:23 B6m3dSPJ
こんな所に・・・・
誤爆しました。失敬。
739:login:Penguin
10/04/12 08:45:24 i6AEo9WC
こんなところとは失礼だな君は
740:login:Penguin
10/04/12 09:35:28 TaBB+zUC
まあまあ、こんなところというのは良い意味で言ったんだよな、坊主
741:login:Penguin
10/04/15 01:17:11 GwN4l2eh
ついでだからgitについてもひとこと書いてけ、坊主
742:login:Penguin
10/04/15 15:39:46 VoGIIRW/
webdav経由の速度がsvn(mod_dav_svn)に負けるんだけど。
どこが早いだよ。ボケが。
743:login:Penguin
10/04/15 15:40:06 VoGIIRW/
とと間違えた糞がだった。gitだけに。
744:login:Penguin
10/04/15 16:15:54 /XEu1xEv
webdav経由なんて使ったことないな。速度って何の速度？ クローンじゃないよね？
745:login:Penguin
10/04/16 08:09:07 UzWc4Tj9
webdav(笑)
746:login:Penguin
10/04/17 10:38:01 yU9e03Tm
>>741
ぎったんぎったんにしてやんよ
747:login:Penguin
10/04/19 12:01:21 9Dj8CBQk
>>744
クローンだよ。
初回はやっぱりクローンだし。
LLのコード管理するならいいけど
中間コード生成する類のコードだと余計ファイルを一掃したくなるので
中央からクローンする頻度が上がる、クローンが遅いのは痛い。
零細企業の事情は知らんけど、そこそこの企業ならポート制限をかけてて
git用に別ポート開けろとかいやがられるので80ポートは開いてるからwebdav
748:login:Penguin
10/04/19 12:24:28 T4uQ6+sS
>>747
だまってsvn使えばいいじゃない
gitのクローンって、リポジトリのクローンだよ？
速度を比べるのがおかしい
749:login:Penguin
10/04/19 12:55:20 4DqhZF3F
>>748
だな、速度を比べるのならsvnではr1からHEADまで全履歴を取得させて計測すべき。
750:login:Penguin
10/04/19 15:21:58 9Dj8CBQk
>>748
たしかにsvn使う方がいいですね。そうします。
中央リポジトリだけsvnにしてもいいんだけど
それだとブランチ毎にcloneしないといけないっていうのが使いにくい。
Linusさんが作ったわけだから、中間コードを生成するようなものにも
利用してるはずで、多分私の運用方法がまずいと思うんだけど。
git系の解説書見てもよく分からん。
751:login:Penguin
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経由だと最後の方法しかダメ？