09/08/14 10:12:25 vxCEaCUs
アドバイスを元に /etc/xinetd.d/git の user/group などを root にしてみたところ、
/var/log/message のエラー内容が変わりました。
$ tail /var/log/message
git-daemon: [25819] unable to allocate any listen sockets on host (null) port 9418
$ lsof | grep git
git-daemo 25772 root cwd unknown /proc/25772/cwd (readlink: Permission denied)
git-daemo 25772 root rtd unknown /proc/25772/root (readlink: Permission denied)
git-daemo 25772 root txt unknown /proc/25772/exe (readlink: Permission denied)
git-daemo 25772 root NOFD /proc/25772/fd (opendir: Permission denied)
ハマってきたので zypper remove git-daemon して、
ゼロからやり直してみたところ、やはり同じ症状に…。
openSUSE スレで聞いた方がいいのかもしれませんが、
その前に、ここでお分かりになる方はいらっしゃいますでしょうか。
422:login:Penguin
09/08/14 10:35:16 Q/iZulHO
>>421
URLﾘﾝｸ(www.aoisakura.jp)
おなじエラーではまってる人がいました。
以前動かそうとしていたものが正常終了していないのでは?
423:421
09/08/14 10:56:54 vxCEaCUs
ありがとうございます。
プロセスを kill -9 し、xinetd を再起動しました。
$ sudo lsof | grep git
xinetd 26055 root 5u IPv4 1666608 0t0 TCP *:git (LISTEN)
$ sudo kill -9 26055
$ sudo /usr/sbin/rcxinetd restart
今度は readlink: Permission denied が出ないのでいい感じ！
$ sudo lsof | grep git
git-daemo 26095 git-daemon cwd DIR 253,3 4096 2 /
git-daemo 26095 git-daemon rtd DIR 253,3 4096 2 /
git-daemo 26095 git-daemon txt REG 253,3 196936 10356883 /usr/lib64/git/git-daemon
git-daemo 26095 git-daemon mem REG 253,3 47784 9946462 /lib64/libnss_files-2.9.so
( 省略 )
git-daemo 26095 git-daemon 2u CHR 1,3 0t0 2055 /dev/null
git-daemo 26095 git-daemon 3u IPv6 1666970 0t0 TCP *:git (LISTEN)
git-daemo 26095 git-daemon 4r FIFO 0,7 0t0 1666971 pipe
git-daemo 26095 git-daemon 5w FIFO 0,7 0t0 1666971 pipe
xinetd 26136 root 5u IPv4 1667341 0t0 TCP *:git (LISTEN)
と思ったのですが、
windows> git clone git://example/test/test.git
fatal: read error (Software caused connection abort)
$ tail /var/log/message
git-daemon: [26178] unable to allocate any listen sockets on host (null) port 9418
と変わらず…。openSUSE を再起動してみます…。
424:421
09/08/14 11:00:50 vxCEaCUs
余談。
zypper install git-daemon で作られる /etc/xinetd.d/git には
--base-path="/srv/git"
と書かれていて、" を消して
--base-path=/srv/git
としないといけなかった。
昨日からハマっているので、午前中の段階で精神的に疲労中ｗ
425:421
09/08/14 11:14:13 vxCEaCUs
再起動しても
$ sudo taile /var/log/message
git-daemon: [3288] unable to allocate any listen sockets on host (null) port 9418
$ sudo lsof -i:9418
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
xinetd 2903 root 5u IPv4 6924 0t0 TCP *:git (LISTEN)
git-daemo 3296 git-daemon 3u IPv6 9929 0t0 TCP *:git (LISTEN)
xinetd と、普通のサーバが二重に立ちあがっているのが原因でしょうか ( しかも IPv6 )。
git-daemon を kill -9 しても自動で立ち上がります。
これを止める方法を探しますが、アドバイスがあると嬉しいです。
426:login:Penguin
09/08/14 11:23:39 Q/iZulHO
xinetdから起動されたgit-daemonが、リクエストを処理し終わっても
そのままデーモンとして残り続けていませんか?
xinetdから起動するなら、処理ごとに終了するべきですね。
git-daemonに渡せるオプションはありませんか?
--inetd だろうか。
427:421
09/08/14 11:43:01 vxCEaCUs
>>429
本当にありがとうございます！！
git clone できました！！！
今後の人のためにまとめると、
openSUSE 11.1 で
$ sudo zypper install git-daemon
したのを ssh 使わずに利用したいなら
/etc/xinetd.d/git を下記に変更。
■ BEFORE
server_args = daemon --syslog --detach --reuseaddr --user=git-daemon --group=nogroup --pid-file=/var/run/git-daemon.pid --base-p
ath="/srv/git"
■ AFTER
server_args = daemon --syslog --detach --reuseaddr --inetd --export-all --pid-file=/var/run/git-daemon.pid --base-path=/srv/git
変更後、xinetd の再起動を忘れずに。
$ sudo /usr/sbin/rcxinetd restart
あー、今日はもう帰ってビール飲みたい。
428:427
09/08/14 11:43:52 vxCEaCUs
興奮して間違えましたが、429 さんではなく、>>426 さんです。
そのほか、いろいろ助言を下さった方、ありがとうございました。
429:login:Penguin
09/08/17 12:41:58 w4WoSrsO
read only で構わないのですが、linus 達がいじっている
linux kernel tree 本線を git で、ローカルのlinux PC 上に
同期できるでしょうか？その場合、どうすれば良いですか？
430:login:Penguin
09/08/17 13:25:08 IIDjTJ7I
linux kernel git torvalds
でぐぐれ
431:login:Penguin
09/08/17 14:01:07 w4WoSrsO
ありがとうございました。逝ってきます。
432:login:Penguin
09/08/18 00:02:03 cqrV6ZTW
>>429
>read only で構わないのですが、
433:login:Penguin
09/08/18 14:17:17 LNnWooNT
コミットの適切な粒度がわからない
GitHubのNetworksでどばっと20個くらいドットが突出すると悩む
これやっぱ手作業でまとめておくべきだったかもしれない、とか
手元のコミットは細かくして公開するブランチに追加するときにまとめるのがいいのだろうか
でもコミットを1個ずつ扱うのってブランチのメリットなくね、とも思ってみたり
マージとかができてこそのブランチだろう、とも思う
434:login:Penguin
09/08/18 14:41:53 Kn1/NE8Q
>>433
何がしたいのかが分かって、適度な量の差分があって、機能単位にまとまっていれば
（混ざり合っていなければ）それでいいんじゃないかな。
後はバリバリ作り中なのか、機能追加中なのか、とか、、、
同時にコーディングしてる人の数にもよるね…
俺はキレイなコミットを作りたいほうなのでけっこうまとめてからにしてしまうなぁ
435:login:Penguin
09/08/18 22:05:49 Gf8+h6+U
最近、なんかgitの勢いすごいね
そこら中で使われはじめて
リーナスのいうように、kernel特化でほそぼそといくと思ってたよ
436:login:Penguin
09/08/19 12:38:13 pceGE7iL
hg派だったがリスク分散のため入門gitで勉強中。
微妙な違いがいやらしいなぁ。
viとemacsは同時に使えるが
hgとgitはかなり混乱しそうだ。
437:login:Penguin
09/08/19 23:02:46 O0WnAYMJ
monotoneどうよ？
438:login:Penguin
09/08/20 04:02:05 2o0Eo2gm
>>433
そんなレベルの人間が公開なんかするな
迷惑だから
439:login:Penguin
09/08/20 04:24:39 amhGymTU
.|
.|
∩＿＿＿∩ |
| ノ＼ ,＿ ヽ .|
/ ●゛ ● | .J
| ∪ ( _●_) ミ
彡､ |∪| |
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
＼ " ／ ｜ |
＼ ／￣￣￣ ／
440:login:Penguin
09/08/27 18:25:34 AEidpR6i
git push した時に表示される、
Total 15 (delta 13), reused 0 (delta 0)
の delta や reused って何でしょうか？
441:login:Penguin
09/08/27 19:25:19 HNb4zbwi
git を使い始めて、また git 関連の文書を読んでて気になった点。
・index, cached, stage といった用語を一貫して欲しい
・obj, ref などが何の説明もなく頻繁に登場するが、何を指しているのか不明
442:login:Penguin
09/08/27 21:44:24 KnkKlcU8
>>441
>index, cached, stage といった用語を一貫して欲しい
MLしばらく読んでからパッチ送る、とか。
>obj,ref
git help tutorial-2
あたりかな?
443:login:Penguin
09/08/28 07:32:58 sWD41Zdb
>>441
> ・index, cached, stage といった用語を一貫して欲しい
無理。indexで統一できなくはないけど、どういう使い方をしているかで呼び分けてるから。
ML漁ればどういう意図で呼び分けてるかの回答はあるよ。
444:login:Penguin
09/08/28 08:05:49 fZ8G9Ga3
それじゃダメだろふつー
用語集はつけとくべきだな
445:login:Penguin
09/08/28 12:15:32 cXIbI/jo
stageは利用者側の視点。
indexは実装者側の視点。
cacheはどういう発想なのか不思議。
446:login:Penguin
09/08/28 13:53:30 xwPQ04ed
用語集も見つけられないの? 何なの?
URLﾘﾝｸ(www.kernel.org)
447:login:Penguin
09/08/29 14:57:13 U8/P76bc
>446
cache Obsolete for: index.
えらそうなこった
448:login:Penguin
09/08/29 16:10:23 +Pa25OBz
ところで
> Truth be told, it can also contain a second, and even a third version of a working tree
これHamanoさんか誰かの講演を聞いた人のメモで読んだことが
あるのを思いだしたんだけど、てことは何度かgit stageしたそれぞれの
バージョンをみたり、バージョン間で差分見ることができるってこと?
もしそうなら、どういうコマンドでできるの?
449:login:Penguin
09/08/31 02:43:09 VXNlRilH
git のドキュメントを読んでいる最中なのですが、
subversion と違って履歴を持つオブジェクトの概念があるわけではないので
subversion のような改名いかんに関わらず履歴やdiffを追えるという特徴は
git にはないと理解しました。あってますか。
450:login:Penguin
09/08/31 11:11:59 kZiorwCa
git commit -m でコマンドラインから直接コミットログを書いた場合と
git commit で開いた vim から書いた場合で文字コードが違った(上記はUTF-8,vimはiso-2022-jp)ので、
git log 等で見ると vim から書いた方が文字化けしてしまいました。
git log --encoding=iso-2022-jp とすれば文字化けせずに見られるのですが、やはり文字コードを統一したいので log を直接編集したいのですが、
.git/logs/HEAD
.git/logs/refs/heads/master
を編集しても文字化けは解消されませんでした。
どのファイルを編集すればよいのでしょうか？
451:login:Penguin
09/09/01 01:17:08 BBTYztuT
>>449
git log -p --follow <path>
452:login:Penguin
09/09/01 01:22:40 BBTYztuT
>>450
git commit --amend
でHEADのコミットメッセージ入力をやりなおせる
または、
git reset HEAD^
で一旦HEAD^まで戻してやりなおす。
ちなみに
git commit -F <file>
でファイルからコミットログを読ませることが可能なので試してみて
試してないが -amend との同時利用も可能なんじゃないかな
453:login:Penguin
09/09/01 06:39:58 BUwsap/v
>>451
どうも。コミットを追跡することでやっているみたいですね。
でもmv後修正してからコミットしたり、あるいはcpでフォークしたり(ファイル
を分割するときとか)はやはり追跡できないみたいですね。
454:login:Penguin
09/09/01 11:24:42 qONSM/kc
>>450 を読んで気づいたけど、
command line のcommit log の文字コードって、今まで考えてもいなかったよ。
で、i18n.commitEncoding と i18n.logOutputEncoding の値を、
変えて色々試してみて、ワザと異なる文字コードの時の動作が
しっくりこなくて調べた。
解ったことは、
message が commit object に格納される時って、
文字コードを変換してくれるんじゃなくて
i18n.commitEncoding で、指定した値をcommit object に
encoding EUC-JP
って、挿入してるだけなのね。
encoding で指定しない時が UTF-8 で、これがデフォルトってことみたい。
出力時にi18n.logOutputEncoding を元に変換する。
だから、commit message も、raw って言えば raw なのね。
ん 、知りませんでした。ビックリ。
これで、コード変換に纏わる面倒な部分を、(出力時にまわして)
うまく避けてることになるのかな。
455:login:Penguin
09/09/01 12:01:26 bYVC5N8B
tortoisegitの話題はここでいいんだろうか。
indexの存在を完璧に隠蔽しているのはかなり大胆な設計だと思う。
456:login:Penguin
09/09/01 12:38:37 Cu6PEjTW
>>452
ar
457:login:Penguin
09/09/01 12:39:46 Cu6PEjTW
>>452
ありがとうございます。出来ました。
--amend は直前のコミットしか編集できなかったのですが、
URLﾘﾝｸ(www8.atwiki.jp)
を見て、git rebase と組み合わせると以前のコミットでも修整できることが分りました。
>>456 はミスです...
458:login:Penguin
09/09/01 15:48:31 cQoB1n74
修正、ではない
残念ながら
459:login:Penguin
09/09/01 17:44:29 Cu6PEjTW
>>458
古いコミットを削除？して新たにコミットしている、という事でしょうか？
460:login:Penguin
09/09/01 19:42:56 +F0cM0kX
ハッシュ見れ
461:login:Penguin
09/09/01 20:44:28 2vtwePxM
>>460
なるほど。
git show "古いハッシュ"
で、古いコミットのログが見れました。
削除はしてないんですね。
462:login:Penguin
09/09/01 21:41:34 miUg4h5c
>>461
gcしたら消えるよ。どこからも参照されてなければ。
463:login:Penguin
09/09/04 22:13:13 jVdAqUn/
あるリポジトリとそのミラーがいくつかあって、最初にcloneしてきた
ところから普段はfetchしている
$ git fetch
んですが時々別の場所からfetchしたい場合があります。
$ git fetch another_mirror
こういう場合、各ミラーをそれぞれremoteとして登録すべきなんで
しょうか。調べた限りではurl.<url>.insteadof=<alias>を
使ってURLに別名をつけられるのですが、fetchコマンドの最初の
引数にこのURL別名だけを与えても実際にはデータが落ちず、refspec
まで書かないといけなくて面倒です。
464:login:Penguin
09/09/11 20:42:02 Crcv3Tii
間違えた commit は git commit --amend で戻せますが、
git push したのを取り消すにはどうしたらいいでしょうか？
465:login:Penguin
09/09/11 21:24:08 GPAiiF+d
>>464
「取り消す」というのがamendしたものを反映したいという意味なら
git push -f
で上書きできるよ。
466:login:Penguin
09/09/11 21:34:54 Crcv3Tii
>>465
ありがとうございます。
history からも消すことはできますか。
467:login:Penguin
09/09/11 21:37:03 GPAiiF+d
>>466
> history からも消すことはできますか。
んん? 何を消したいのかもう少し詳しく。
468:466
09/09/11 22:41:07 Crcv3Tii
>>467
github に git commit & git push してから間違いに気づいてしまったのです。
それを消したいのです。git log から消えたり、
github は history を見ることが出来ますが、それからも消えるとありがたいです。
469:login:Penguin
09/09/11 22:47:34 CyE8alMj
>>468
何もかも上書きさるよ。
ただgithubってことは既に公開されてるから、他の人があれ何だこれこわい、
ってなるかも。つまりあんまやるべきじゃない。
470:466
09/09/11 22:50:59 Crcv3Tii
>>469
ありがとうございます。
確かに消すのはよくないですよね。
( 別の場所から commit したから名前を間違えてしまってｗ )
471:login:Penguin
09/09/16 17:10:33 YPgdd8OB
リモート側にpushされてきた変更を反映するのってどうやるんですか？
git log では表示されるんですけど、master に反映されていません・・・。
472:login:Penguin
09/09/16 17:13:27 XD22rFwt
>>471
「反映」を適当に解釈してエスパーしてみると、
git pull
473:login:Penguin
09/09/16 17:19:00 YPgdd8OB
>>472
リモート自身に push されてきたものを、自身の master に反映させる、でした＾＾；
リモート(origin)側で git pull する場合ってどう指定するんでしょう？
474:login:Penguin
09/09/16 17:40:50 XD22rFwt
>>473
「自身の master に反映させる」なら git pull だよ。
リモート(origin)側をどうにかしたいの？
475:login:Penguin
09/09/16 18:07:18 YPgdd8OB
>>474
はい。その通りです。
サーバに置いたoriginに対してローカルからpushした結果を、originのmasterに反映させたいんです。
476:login:Penguin
09/09/16 18:45:32 XD22rFwt
>>475
ローカルのmasterをoriginのmasterに突っ込むにはこう
git push origin master:master
文章から推測するにいまひとつ理解できてないようなので、この辺を読むことをオススメします
URLﾘﾝｸ(www8.atwiki.jp)
477:login:Penguin
09/09/16 19:43:56 JwlYDLcs
リモートがbareじゃないのでは?
git checkout -f HEAD
478:login:Penguin
09/09/16 22:23:53 Wm2GOTku
『リモートに push したのに反映されていない』とエスパーしたが
それなら git remote update だよ
479:login:Penguin
09/09/16 23:36:01 YPgdd8OB
皆さんレスありがとうございます。
仰る通りリモートは bare じゃないです。
git checkout -f HEAD
でリモートの状態を最新にできました！
ありがとうございました！
480:login:Penguin
09/09/17 01:26:37 P4kqmOWE
?
481:login:Penguin
09/09/21 13:23:23 GwGS71uz
gitメンテナであるHamano氏自身による「入門Git」発売記念age
URLﾘﾝｸ(www.shuwasystem.co.jp)
# 翻訳本の「入門git」じゃないぞ
Amazon はすでに売り切れ状態みたいだけどね。
482:login:Penguin
09/09/21 13:34:20 zscoFCMs
gitは使われ始めたばかりだから、一番最初にgitの解説書書いたら、売れそうだな
483:login:Penguin
09/09/21 13:57:00 ZVNst0Rd
>>482
？？？
484:login:Penguin
09/09/21 14:34:05 vL4ajUNH
>>481
ぎゃー
つい最近翻訳本のほう買っちまったぜ…
Hamanoさんが書くべきだろとは思ってたけど、書いてたのか～
目次だけ見たけどすごいしっかりしてそうだ。読むのが楽しみ！
485:login:Penguin
09/09/21 14:36:17 Sxx9inOy
まあ、翻訳本もPragProgブランドだし、損にはならないんじゃね?
486:login:Penguin
09/09/21 14:57:30 GwGS71uz
>>484
ここを読んでもっとwktkするがよい
URLﾘﾝｸ(gitster.livejournal.com)
487:login:Penguin
09/09/21 21:31:18 vL4ajUNH
>>486
ありがとう、livejournalか、そこ知らなかったよ。
wktkが止まらないので、明日本屋うろついてくる。Amazon売り切れ過ぎ、入荷予定遅すぎ。
488:login:Penguin
09/09/22 20:31:15 ssamdIV8
きっと、Linusの「はじめに」の最後の一文を読んで、
にんまりしてしまうに 1000カーネル
489:463
09/09/23 18:27:17 vjEE4TYp
誰か...
490:login:Penguin
09/09/23 21:43:44 jo5qX9Sx
>>463
remote 登録すると明示的に指定しなくても、そのリポジトリの全ブ
ランチを fetch してくれるのは.git/config 内でそのリモートリポ
ジトリの設定の fetch の行におまじないが書いてあるから。
別名定義したいほどの頻度で使うなら素直に remote add しろや
491:login:Penguin
09/09/23 22:37:49 O/8ntIxQ
>>490
＞別名定義したいほどの頻度で使うなら素直に remote add しろや
>>463にはすまんが、俺もそう思ってた。
てか、refspecまで書かなきゃダメ、とかいろいろ試してみたんだったら、
MLで質問したほうが良いんじゃないかな。bugかもしれないし。
492:login:Penguin
09/09/24 00:06:18 h3tEtuix
>>491
んー。fetch の refspec はリモートリポジトリのどのブランチをロー
カルのどの参照名で格納するか(remote/<hoge>/master とかね)を指
定するものだから、 fetch のときに指定必須(*1)なのはしょうがな
いんじゃね？gitからしてみりゃ「どこに格納すりゃいいのよ？」っ
て話でしょ。普通はそれが面倒だから remote 登録しちゃえば？と
思うんだけどねー。
*1 何も指定しなければリモートの master がローカルの
FETCH_HEAD として格納されるはず。
「全部 fetch して remote/<URL>/* に自動的に格納されろや」とか
いう話ならMLに提案するほうがいい話だと思う。もし提案するとし
てもremote add するよりも、「デフォルトでrefspecを指定しない
場合にその挙動をとるほうがより優れている」、という論拠が必要
だと思うよ。
あと、もし pull request 受けるような状況であれば、みんなpull
用のbranch切って pull しちゃってる(or master に pull して結果
が気に入らなければ reset )だろうから、単発の fetch のrefspec
指定を楽にしたい理由があんま思いつかない。
493:login:Penguin
09/09/26 14:03:44 EEvSsK+s
最近GitHubが重いと思う
GitHubの収益源ってなんだっけ？
494:login:Penguin
09/09/26 16:19:01 1VrklZ1N
有償アカウントとか講習会とか業務への導入サポートとか。
鯖はEngineYardだな。
495:login:Penguin
09/09/28 11:57:44 tMILVOon
それだけで賄えるものなのか
496:login:Penguin
09/09/28 17:40:21 9izAOEVd
時々サーバ死んでるよね
タダで使い倒しておいてあまり文句いう筋合いもないけれど
497:login:Penguin
09/09/28 18:11:25 tMILVOon
無料でしか使う予定はないけど頑張ってほしい
498:login:Penguin
09/09/28 18:13:49 JZFsKZPh
URLﾘﾝｸ(fi.github.com)
そういえば、こんなのあったね。
499:login:Penguin
09/09/28 22:56:07 oz2dR2We
Gitはじめてなのですが、バイナリの履歴はすべて持っているのでしょうか？
それとも差分だけ？また、ローカルリポジトリには圧縮されたバイナリはどのように
保存されるのでしょうか？バイナリサイズが大きいプロジェクトで使用予定なのですが
ローカルリポジトリが膨れ上がるのを恐れています。
500:login:Penguin
09/09/29 21:45:20 bBdN/JgI
.git/objects の下を覗きながらcommitしていくと、git gcで
(あるいは時間が来て)packされるまではそのままのバージョンが
残ってるみたい。
mkdir foo
cd foo
git init
dd if=/dev/urandom of=BIN bs=1024k count=1
git add .
git commit -m 1
du -hs .git
echo -n A >> BIN
git add .
git commit -m 2
du -hs .git
find .git/objects -type f
git gc
du -hs .git
501:login:Penguin
09/09/29 23:05:28 RwaZJqu/
thunks! 時間がくれば pack されるのですね。
まあ、HDDスペース節約よりは速度重視な最適化というわけですね。
HDDは、いっぱい増やすしかないかぁ。
後 Windows のファイル名の日本語処理がまずいところが不満ですね。
これさえ解決すれば svn から乗り換えるんだけどなぁ。来年ぐらいかなぁ。
502:login:Penguin
09/10/02 20:43:35 N5w8ligl
>>494
あれなんかEngine Yardじゃなくなってるぽい。
こないだのメンテで移動したのかな。
503:login:Penguin
09/10/05 13:23:59 wUrA1+B2
なんか新しい本買った人いる？
504:login:Penguin
09/10/05 13:27:13 Llm7fIHP
"pro git" pdf
でぐぐれば面白いのが見つかるぞ
505:login:Penguin
09/10/07 07:24:37 GcizbF6G
git clone git://git.example.org/cgit.cgi/xyzzz/tree/?h=newton
git で下の階層に置かれている newton を
持ってくるにはどうしたら良いのでしょうか？
xyzzz を持ってくるのはできるのですが…
506:login:Penguin
09/10/07 07:53:19 GcizbF6G
自己解決 >>329-334 辺り感謝
git clone -n git://git.example.org/xyzzz
cd xyzzz
ls
git checkout -b newton
git fetch
で取りあえず上手く取ってこれるみたいでした
なんでも一行でやろうとするなじぶん('A
507:login:Penguin
09/10/07 20:16:41 9QifAEec
>>506
git cloneで既にfetchしているんでcheckoutの後にfetchしなくても
508:login:Penguin
09/10/09 23:56:02 zcQ4FwK0
>>501
>後 Windows のファイル名の日本語処理がまずいところが不満ですね。
$ git config core.quotepath true
でもだめでしょうか。
509:login:Penguin
09/10/10 10:37:00 qzf82yAL
> git config core.quotepath true
cygwin 版の話ですかね。基本エンジニア以外も触るのでTortoiseGit の(MSYS版)でコミット
した後の亀が飛んで行ったところのメッセージが必ず文字化けしているのがちょっと嫌ですね。
また現在 svn を利用していてこちらを git-svn で使用したいのですがこれも MSYS版には
入っていないようなのでそこもネックになっています。
510:login:Penguin
09/10/10 11:19:34 KZzP/TMn
>>509
msysgit(PortableGit-1.6.3.2-preview20090607) + TortoiseGit 1.0.0.2にて
git-svn をGUI経由で使えてますよ
git-svnにはハマリどころがありました。
svnリポジトリとシンクロしているgit側ブランチでgitのマージコミットをつくったりすると
git svn dcommit時にエラーになるので要注意ですね
ここらへんに情報があります
URLﾘﾝｸ(learn.github.com)
Rules and Guidelines
511:login:Penguin
09/10/10 19:49:42 mLaG7GzK
TortoiseGit に同梱されている
512:login:Penguin
09/10/10 19:51:42 mLaG7GzK
途中での書き込み、すまん。
TortoiseGit に同梱されている igit.exe のソース
どこにあるか、知っている人いたら教えてもらえないだろうか？
どうも TortoiseGit のリポジトリの中にはなさそうなんだけれども。
513:login:Penguin
09/10/10 19:57:24 6WX0ZYRA
Linux板でWindowsのソフトの話すんなよ
514:login:Penguin
09/10/10 20:14:31 zeXst2F3
Windows版のgitはまだまだだよって、開発者自らいってて、どんどんフィードバックしてくれって言ってるんだから
Windowsでgit使いたいんなら、フィードバックしないと一向に改善されないと思うよ
git開発者は、Windows特有の問題とか疎いだろうし
515:512
09/10/10 20:47:16 mLaG7GzK
重ね重ねすまん。
スレタイのみで検索して書き込んでしまった。
分散型バージョン管理システムのフロントエンドを
git の Windows 版フロントエンド作りたいなぁと思って
TortoiseGit のソース見てたんだが、
516:login:Penguin
09/10/10 20:48:31 mLaG7GzK
また、途中で書き込んでしまった。
ごめん、反省した。途中だけど、もうやめる。
517:login:Penguin
09/10/10 21:07:24 5i7bVBSp
>>513
次スレはム板にする？
518:login:Penguin
09/10/10 21:26:06 e4Crdqki
ここ、隔離スレかと思ってたんだが
519:login:Penguin
09/10/11 00:39:32 9BCQsKnT
Windows上でgit使ってる奴なんかいなんだから、Windows特有の問題なんかしらないってことでしょ
520:login:Penguin
09/10/11 02:33:37 FePGrTfs
>>512 恥ずかしいやつ過ぎるwwwwwwwwww
521:login:Penguin
09/10/11 02:44:24 MLGHRsF4
>>515,517
プログラム板にバージョン管理システムのスレあるけど、、、
ｽﾚﾘﾝｸ(tech板)
板違いにはならないだろうけど、、、コアな話題はここでも良いんじゃないかなぁ
>>519
あっちのスレ見てると、使ってる人居るみたいだよ。
日本語ファイル名で苦労するようだけど、UTF-8 Cygwinではちゃんと使えてるらしい。
522:login:Penguin
09/10/11 02:50:26 9BCQsKnT
そりゃ、あっちのスレではいるだろうよ(あっちがどこなのか知らんけど)
ここはLinux板
523:login:Penguin
09/10/11 03:22:42 MLGHRsF4
＞Windows上でgit使ってる奴なんかいなんだから
ってお前が言うから、教えてやったんだぜ。
524:login:Penguin
09/10/11 03:40:02 9BCQsKnT
この板だろうが、あほ?
525:login:Penguin
09/10/11 03:41:49 FePGrTfs
安価もつけてない２ちゃんのレスを自分だけのメッセージって思うようになったら
終わりだぜ。しばらくmixijかtwitterでもやってたほうがいい。
526:login:Penguin
09/10/11 12:14:56 bj1WkRKb
は？ LinuxもWindowsも両方使ってる奴だって居るだろうが、カス？
527:login:Penguin
09/10/11 14:55:39 tk3kki/A
で、ここは本スレなのか？
528:login:Penguin
09/10/11 15:00:46 h+3Jm6y9
一応。
529:login:Penguin
09/10/11 15:03:12 h+3Jm6y9
まあ今はム板にある Subversion スレも、この Linux 板の卒業生だしな。
530:login:Penguin
09/10/11 20:01:14 EMO8XszP
[ANNOUNCE] GIT 1.6.5
URLﾘﾝｸ(article.gmane.org)
531:login:Penguin
09/10/11 23:51:09 5ur/s6Zl
Git-1.6.1-preview20081227.exe から Git-1.6.4-preview20090730.exe に
乗り換えたら確かに git-svn を TortoiseGit から使えました。Windows も実用段階
に入ってきましたね。
532:login:Penguin
09/10/12 12:09:24 cIqY6mPO
>>531
>Windows も実用段階に入ってきましたね。
きっとﾋﾞﾙｹﾞｲﾂも喜ぶよ、それ言ってやったら。
533:login:Penguin
09/10/15 23:02:27 eyJUfiVx
【恐怖の】呆れるほど危険な民主党の正体【民主党】
http:／／www.yo●utube.c●om/watch?v=●MUv12Ae7ojE
小沢一郎 ～ 闇の系譜 ：秘書逮捕の真相／北朝鮮との黒い関係 高画質
http:／／www.yo●utube.com/w●atch?v=gdKVt●_vKCHc
2/3【イリハム・マハムティ】東トルキスタンの歴史と中共の弾圧[H21/7/8]
http:／／www.you●tube.com/watch?v=6eUN●hjdBLXg
漫画で学ぶチベット問題
http:／／www.ni●covideo.jp/w●atch/sm275●2213
日米規制改革および競争政策イニシアティブに基づく日本国政府への米国政府要望書
URLﾘﾝｸ(japan.u)●sembassy.●gov/j/p/tpj-j2●0041020●-50.html#mineika-s
●の部分は外してブラウザのURLに入れること
534:login:Penguin
09/10/21 13:42:46 c6oQncZ5
もしかして git って名前通り、日付指定で checkout できないの？
やっぱ馬鹿。
535:login:Penguin
09/10/21 21:06:25 l0alaDlx
>534
なぜできないと思ったのか詳しく。
536:login:Penguin
09/10/21 21:07:29 aa6m0+r8
>>534
おみゃーがgitなんでは
537:hNhmZvkzyoOKS
09/10/23 00:55:36 AJC23NiC
But while these inter- ventions slowed the adjustments of the market, these adjustments were still in ultimate control of the situation. ,
538:VfpxZeUExLhxZWcT
09/10/23 22:20:46 iDEpw1qy
This initial post on Every Kitchen Table frames the need for new food systems connecting more consumers with sustainably grown, processed and transported food. ,
539:login:Penguin
09/10/28 22:39:14 5N68sDZB
最後にコミットした時のログメッセージの再編集は git commit --amend でできるのですが、
何世代も過去のコミットのログメッセージの再編集はどうやればできるのでしょうか。
それともそんなことはできないんでしょうか。
540:login:Penguin
09/10/28 22:53:34 oPxfRTK5
git rebase -i HEAD\~5
みたくやって pick を edit にして、--amend の時に変更かな
541:login:Penguin
09/10/28 22:53:38 ZAqclN9p
>>539
色々やり方あると思うが、例えば git rebase -i ... で編集したい commit を "edit" に設定
して、そこで git commit --amend とか
542:login:Penguin
09/10/28 22:54:51 Bv3SPJWB
URLﾘﾝｸ(progit.org)
543: ◆Mizar2to32
09/10/29 20:21:01 25uBABNp
git gui は日本語UIにできるのに、 gitk はできないのも妙に思い、日本語訳を試みてみました。
妙な日本語訳の改善案などがあればお知らせください。
URLﾘﾝｸ(lab.mzr.jp)
544:login:Penguin
09/11/02 10:53:06 dHnBQYx7
>>539
脳内で考えるような「単純な差し替え」は厳密にはできない
「以前と同じ修正群と、以前と違うコミットメッセージ」を持ったコミットの列を作って繋げなおす、という手順になる
動作的には同じだが、オブジェクトとしては別だし、ハッシュ値も違う
push した後だと以前のコミットと同一視させる手段がなくてたいそう悲惨
545:login:Penguin
09/11/02 22:10:38 tm2FQ3Ct
もちろんそれは正しいけど、commit --amendを持ち出してる
のを見ると、そこらへんは分かってるように見える。
546:login:Penguin
09/11/12 18:58:57 g557GIl1
Gitの実装はいつCからGoに切り替わりますか？
ｽﾚﾘﾝｸ(tech板:90-番)
547:login:Penguin
09/11/12 21:02:35 ExEkAwfK
>>546
どっちだ?
URLﾘﾝｸ(golang.org)
URLﾘﾝｸ(books.google.com)
548:login:Penguin
09/11/18 09:19:34 F9Vk+fo2
git pull --rebaseしたのですが、
Applying: コミットメッセージ
usage: git update-ref [options] -d <refname> [<oldval>]
or: git update-ref [options] <refname> <newval> [<oldval>]
-m <reason> reason of the update
-d deletes the reference
--no-deref update <refname> not the one it points to
と出てしまいます。
git rebase --continueしても同じメッセージが出ます。
どうすればいいんでしょうか？
549:548
09/11/18 15:11:19 F9Vk+fo2
git fetchして、git rebase masterすると同じメッセージが出たのですが、
git rebase -i masterすると問題なくリベースできました。
解決はできたのですが、なぜgit rebase masterでリベースできないのに
インタラクティブモードではできるのか、わけがわからない・・・
550:login:Penguin
09/11/18 18:47:37 d8p7qpgP
>>548
rebaseの内部でコケてるみたいだけど、遭遇したことないなあ。
バージョンは？ もしかしてCygwinだったり？
551:login:Penguin
09/11/18 22:32:08 vQLD30Z2
>>548
rebase -i masterでリベースできるってことは
ふだん使うブランチはmasterではなくて、
masterっていうローカルブランチがたとえば
ref: origin/master
みたいになってたりするの?
552:login:Penguin
09/11/22 09:56:48 AGTujtCR
すみません、煮詰まってしまったので詳しいかた教えていただけないでしょうか
bareじゃない二つのリポジトリAとBがあります。
（BはAからのクローンです）
Bで変更を行ってAにPushしたあと、Aでgit statusすると
A上ではBで行った変更の真逆の修正が行われてステージされていることになっています。
これはどうしてでしょうか？
純粋に期待している動作（A上でもBで行った修正がコミット済みになっていて何もステージされていない状態）にするにはどうしたらよいのでしょう？
553:login:Penguin
09/11/22 11:17:08 VQCPH5PD
>552
ステージされてるなら git reset なり git checkout . なりすればいいんじゃないの？
554:login:Penguin
09/11/22 12:57:08 KnKStRKz
>>552
bareじゃないとこにpushじゃしょうがないんじゃないかな。
Aでpullしたらいいんじゃない？
555:login:Penguin
09/11/22 18:25:36 AGTujtCR
回答いただきありがとうございます。
>>553
A上で、真逆の修正が行われているものを
すべてgit checkout -- hogehoge.txt
して解除してみたところ結果としてはうまくいきました
>>554
AからBのリポジトリをremoteに登録して、pullしようとすると
Because this is not the default configured remotefor your current
branch,you must specify a branch on the command line.
とおこられます。
デフォルトのリモート先ではないので
先に設定を変えましょうといった感じでしょうか
現状ですと、正しくPushするためにはbareじゃないリポジトリを
用意する必要があると考えた方がいいのでしょうか？
checkoutする方法や都度リモート先を変更するのは手順が煩雑になるため・・
556:552,555
09/11/22 18:28:42 AGTujtCR
間違えました。
誤：現状ですと、正しくPushするためにはbareじゃないリポジトリを
正：現状ですと、正しくPushするためにはbareなリポジトリを
557:552,555
09/11/22 19:14:14 AGTujtCR
たびたびすみません。自己解決しました。
BからAにPushしたあと、Aでgit reset --hard
すればいいだけでした。
返信をくださった方ありがとうございました。
558:login:Penguin
09/11/28 04:29:09 mXZ4Zywn
バイナリファイルがコンフリクトした際にどのように対処してますでしょうか
マージすることが不可能な場合、どちらかのファイルを選択することになりますが
自分の作業を優先してコンフリクト解消する場合には
git add コンフリクトしてるファイル
git commit
これでコンフリクト解消できますが、相手のファイルを優先したい場合に
git reset コンフリクトしてるファイル
git commit
をすると両者の作業がなかったことになってしまいます。
相手の作業を優先する場合にはどのようなコマンドを打てばよいのでしょうか
559:login:Penguin
09/11/28 20:11:39 xkqQAqqu
git checkout --ours --theirs
560:login:Penguin
09/12/03 20:30:50 lBf6Jtla
URLﾘﾝｸ(www.kernel.org)
561:login:Penguin
09/12/04 13:36:14 F6K5uhGt
-----B
/ \
-------A
\
---C
という感じで開発を進めていて、Bの変更はマスターであるAに頻繁にマージしている状態です。
Cで $ git pull A でマージして $ git push A とすると
To prevent you from losing history, non-fast-forward updates were rejected.
Merge the remote changes before pushing again.
といわれてしまう。
なんでnon-fast-forwardな状況なんだかよくわからないです。どうやったら直せるんでしょうか?
562:login:Penguin
09/12/04 22:38:29 8MryHyNF
>>561
pushとpullって名前からしてやることが近い気がしてしまうけど、
pull：remoteをfetchして現在のブランチにmerge（fetchしてmergeするのと同じことが起こる）
push：remoteブランチをローカルのブランチで上書き
なので、pullはfast-forwardじゃなくてもマージコミット作ってくれるけど、
pushはマージはしないのでfast-forwardじゃない時は怒られる。forceオプションで強制pushすると
ヘタするとremoteブランチのコミットが失われる。
fast-forwardの意味が分からない場合は、チュートリアル見ると良いと思うよ。
Git入門 - トップページ
URLﾘﾝｸ(www8.atwiki.jp)
563:login:Penguin
09/12/05 10:43:44 Pt8GWP/i
>>562
「なんでnon-fast-forwardな状況」であるかの説明になっていないけど
564:login:Penguin
09/12/05 13:58:28 dGM7vi/8
>>563
それが分からなければチュートリアル読んだほうが良いと思ったから。
565:login:Penguin
09/12/06 00:13:42 O+n3DTMA
>>564
質問は「なんでnon-fast-forwardな状況」なのかであって
「(non-)fast-forwardとは何か」ではないので、だったら
>>561の説明自体無駄で最初からチュートリアルのURLだけ
案内するのと変わんねーじゃん
566:login:Penguin
09/12/06 03:51:03 3OwwH+xV
>>565
ほんとだ、俺寝ボケてたみたいだわ。ごめん。
>>561
Bの進化分は既にAに反映されているが、Cはそれ以前のAの状態を元に進化しているので、
non-fast-forwardということになる。
567:login:Penguin
09/12/07 12:28:13 XoL3Gt8w
Git 1.6.5.5
URLﾘﾝｸ(www.kernel.org)
＞Manual pages can be formatted with older xmlto again.
568:561
09/12/07 13:26:24 BLewJ948
若干荒れ気味になってすみません。
>566
>Bの進化分は既にAに反映されているが、Cはそれ以前のAの状態を元に進化しているので、
でその通りでした。Cで
$ git pull B
コンフリクト等解決して
$ git push A
でOKでした。
569:561
09/12/07 13:34:18 BLewJ948
で、思ったんですが、non-fast-forwardな原因を追いかけるのはどうやるのが一番わかりやすいですかね?
私の今回の場合、過去にどう作業していたか思い出した、という原始的な方法だったんだけど、便利なコマンドとかありますか?
$ git log --graph
とか見ても、ごっちゃで気づけなかったです。
570:login:Penguin
09/12/07 14:54:49 XoL3Gt8w
>>569
git statusした時に
# Your branch and 'origin/master' have diverged,
# and have 1 and 1 different commit(s) each, respectively.
という感じで出るので、これで分かる。ただしgitのバージョンが古いとこれ出ない。
git show-branchも調べてみたらいいかも。あとgitkはそれなりに見やすいと思うな。
>>561
＞Merge the remote changes before pushing again.
これやってみればいいのに。mergeだけだとマージコミットだらけになっちゃうから、
rebase出来る時はrebaseした方がいいけどね。git pull --rebaseとか。
571:login:Penguin
09/12/08 01:34:52 JrbFTpX+
>>569
gitk --all と打つとグラフィカルにグラフ表示してくれるので
fast-forwardかどうかすぐわかる
572:561
09/12/10 14:41:50 ZxyM+JCY
>570,571
リモートのコンソールにログインして使うことが多いので、gitkは使えないんです。
X飛ばすのも面倒な環境だし。
git show-branch の見かたを覚えることにしますわ。
573:login:Penguin
09/12/11 09:24:45 n6TyF9bQ
git clone すればいいんじゃね？
574:login:Penguin
09/12/12 01:53:51 1uRf1xZK
入門Git買ったんだが、これ分かりやすいな
さすがに濱野さんが書いてるだけあるか。
チームで使うSCMをSubversionからGitに変えたいんだが
メンバー全員に正しいGitの使い方を教育するのは、骨が折れそうだな・・・
575:login:Penguin
09/12/12 02:23:58 7I0ALriM
>>574
入門Git、神本なのは確かだけど、俺としては日本語ちょっとクドい気がしたな。
アメリカ在住らしいから、脳が英語になってるんじゃなかろうか。
Gitって、viとかみたいに取っ付きにくいけど慣れてしまうと手放せなくなる
典型的な麻薬ツールだと思う。そのぶん障壁が高くて文句言われがちなんだけど。
だから「メンバー全員に正しいGitの使い方を教育」するのは、難しいだろうけど
そのぶん感謝もされるし、また始めての人にどう教えたら本質を理解してくれるのか
というのは、とても有用な情報だと思う。
576:login:Penguin
09/12/12 14:40:22 0trcq50X
>>574
良い本だとは思うけど、わかりやすくはないと思う。
まわりを教育するには初心者向けのわかりやすい本が欲しい。
577:login:Penguin
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が
ブランチの場合とタグの場合があるためにこういう状態になって
います。