git スレッド - 暇つぶし2ch

git スレッド ..

372:login:Penguin
09/07/21 04:43:12 nT3Auy6R
論理構造的にはともかく、diffの各行的には単にインデントが浅くなっただけじゃん
module WWW と end のとこだけだろ、それ引っかかるの

373:login:Penguin
09/07/21 12:41:57 Y7zra871
>>366
git rerere --help

374:login:Penguin
09/07/21 13:52:37 HzmMUGDt
GitHubに試しに登録してpushまで終わったんだが、
検索にかからない、自分のIDすらかからない・・・なんだこりゃ

375:login:Penguin
09/07/22 06:38:32 dp/16pzu
>>372
これ、lib/www/mechanize/ 以下のファイルが全部 lib/mechanize/ に移動してるんだよね
手元では lib/www/mechanize/ の中に編集されたファイルがたくさんあるだろうから、
rebase で遡って差分適用するたびに衝突起こすな

376:login:Penguin
09/07/24 14:17:45 6MAoexAT
git commit したら自動で -v オプションを付ける方法はなんでしょうか

377:login:Penguin
09/07/26 10:29:12 r004HONT
>>376
aliasを設定するとか。

378:login:Penguin
09/07/29 21:06:50 NqWOLxIQ
1.6.4 age

379:login:Penguin
09/08/02 06:28:58 ANiJcqBB
URLﾘﾝｸ(ssl.ohmsha.co.jp)
原書はどんなできなのかな？

380:login:Penguin
09/08/02 09:08:14 1MTX0arw
>>379
Pragprogの原書なのでブランド買いした。

CVS/Subversion/Mercurialを使った経験ありの俺的にはそれなりに
使えるようになった。

管理オブジェクトの話とかplumbingコマンドのレイヤーについては
さほど載ってなかったはず。

381:login:Penguin
09/08/02 19:51:08 ANiJcqBB
>>380
レビュー、ありがとう。
この訳本が出たら、立ち読みしてみて、考えよう。

382:login:Penguin
09/08/03 14:34:54 RIRtotud
gitとsquidを連携したwebキャッシュ作りたいんだけど
gitを改造しないでsquidと連携させることできる？

383:login:Penguin
09/08/03 16:11:32 T85XxxMu
git cvsimport
でCVSリポジトリを変換しようと思ったらメッセージが化けました。
今までTortoiseCVS SJIS版（あろはだよCVS版）を使っていたのでそうなったんだと思いますが、
このメッセージをUTF8に変換するにはどうしたらいいんでしょう？
どなたかお助けいただけますと幸いです。よろしくお願いします。

384:login:Penguin
09/08/03 20:24:19 6y63jn1e
>>382
「連携」が何か他の人に伝わってる、と思うのはなぜ?

385:login:Penguin
09/08/06 07:01:18 KCKgFcNy
>>383
おれはEUC-JPなcvsからcvsimportしたやつは、
git config i18n.commitEncoding EUC-JP してるけど。
まああたらしいログをUTF8で書くとやっぱり化けるけど。
基本自分は英字でログかくから気にしてない。

386:login:Penguin
09/08/06 07:05:35 KCKgFcNy
とカキコしてから気になって調べたら、
git config i18n.logOutputEncoding UTF8すると
あたらしくUTF8で書いてもしっかり全部化けずにいけますた。

387:login:Penguin
09/08/10 17:32:11 2cu11IQe
ずっと思ってたんだけど、merge って意味なくね？
一意なハッシュで管理されてるなら cherry-pick だけで十分じゃね？
ローカルなブランチが晒されるしコミットメッセージの編集もできないし merge は害悪しか思いつかないんだが

388:login:Penguin
09/08/10 17:41:46 +bQVdOii
うん、やっぱ言葉が悪いよな

私たちが図を書かず頭のイメージだけで考えるところの「ブランチのマージ」は、
たいていの場合、適切な方向に rebase することで達成される
git を使っていて「マージ」したいと思ったなら、まずは rebase を検討すれ

389:login:Penguin
09/08/10 17:42:14 Ln/irodm
>>387
cherry-pickしたらハッシュ変わるけどどうすんの？

390:login:Penguin
09/08/10 17:59:06 +bQVdOii
たぶん、衝突するようなマージばかりを経験してるのだと思われ

391:login:Penguin
09/08/10 18:11:48 Ln/irodm
公開したらrebase出来なくなって、FFできそうなやつでもmergeするしかなくなるってのは
どうにかならないもんかとたまに思うことはあるな。まあしょうがない気はするけど。

FF出来ない時にマージコミットつくらずに１つの新しいコミットにまとめてしまって、
その上で便宜上だけでも元のコミット群はこれらです、って感じに参照させることが
出来ればいいなーと妄想することがある、けどそれって結局マージと同じことなんだよね。
ただ、受け入れ側でマージコミットを嫌がる場合も多いので、そんな機能もあったら便利かも
しれないとかまた妄想。

392:login:Penguin
09/08/10 20:56:04 i4bAM8hh
えーと、こっちのブランチでcherry-pickしてないのどれだっけ？
とかなる希ガス

393:login:Penguin
09/08/10 21:07:20 IbZ/Z+oA
cp はブランチ作り切った最後に行う
cp を頻繁に行う人はコミットメッセージも cp 時に有機的に書き換えてるはずなので
よっぽど変なまとめ方しない限り大丈夫

ウィンドウ2枚開けて片方に git log の結果を常に表示しながら cp しないといけない状況ばかりなのには同意はしておく

394:login:Penguin
09/08/10 23:47:00 nFA1XbhB
>>391
公開してるリポジトリに直接commitしたりとかしてんの?

395:login:Penguin
09/08/10 23:57:49 Ln/irodm
>>394
いや、pushしてるよ。ただフォーク元も公開してるから。

396:login:Penguin
09/08/11 00:18:25 gCZov+kt
mergeっていけないことなのか？必要悪なのか?

397:login:Penguin
09/08/11 01:51:55 9aVIR9qR
pushしたブランチの履歴は変更してはいけないというルールがあるからな

>>396
衝突しない理想的な世界であれば好ましい
衝突が起こったとたん別のコミットになるからシステムデザイン上は駄目
「AをしてBをしてCをする差分適用」であるコミットが衝突後
「AをしてBをしてXをしてCをする差分適用」というコミットに摩り替わっちゃやっぱ駄目だろ

「AをしてBをしてCをする差分適用であるが、今回に限ってはBのあとにXであるさらなる差分適用がある」
という情報で格納すべき
ハッシュ値は不変で
このコミットを cherry-pick したらまずは「AをしてBをしてCをする差分適用」が試されるべき

398:login:Penguin
09/08/11 06:08:40 od33ZDSx
>>397
ハッシュ値をどうやって計算してるか知らないの?

399:login:Penguin
09/08/11 08:06:48 hQImHIEr
ハッシュ値は全く同じアルゴリズムが使われてさえいればどう計算してもいいんだよ
ハッシュというとファイルをバイト列として利用しなければいけないとしか思いつかない人が稀にいるが

400:login:Penguin
09/08/11 10:38:30 AVaSZeyh
resolveがある場合のgitのマージコミットって、
> 「AをしてBをしてCをする差分適用であるが、今回に限ってはBのあとにXであるさらなる差分適用がある」
におけるXになってない？

そもそもA B Cが何を指してるのかよくわからんが。

401:login:Penguin
09/08/12 15:06:33 8h+T8Ju7
svn でさほど不満はないのですが、ファイル数、ファイルサイズともに
大きなプロジェクトで update, commit 速度が遅く困っています。
git に乗り換えれば速度少しでも早くなるでしょうか？また、各
ローカル側の hdd 使用量は svn より増えると考えておいてよいで
しょうか？

402:login:Penguin
09/08/12 15:53:46 mycJo5BE
>>401
速度はたぶんものすごく早くなると思う。
ローカル側のディスク使用量はそれほど気にならないよ。

ただし操作方法、概念が異なるので、もしも仕事で大人数でやるのなら、
習得させるのにそれなりに工数がかかると思う。

403:login:Penguin
09/08/12 17:45:44 Z/KJAJVW
では、ひとまず svn のリポジトリを、残し一部メンバのみ git 経由で
アクセスする感じで検証でしょうか。ただ、この使い方だと速度面の
メリットはわからないですよね。大プロジェクトなので難しいところ。

404:login:Penguin
09/08/12 18:24:39 FOPhwWTC
>403
今一環境がかんないんだが、大プロジェクトでも
updateとcommitなんて日に一度くらいじゃね？

自分だけgit-svn使えばローカルだけで大抵の用事は済むので、
快適になると思うよ。

405:login:Penguin
09/08/12 18:36:00 Y2NYIgNJ
一日最低 10 回は commit してるなぁ

406:login:Penguin
09/08/12 19:12:05 4qtNGkYm
commit --amend含めると30いくかな

407:login:Penguin
09/08/12 19:48:18 pDDmfa5D
すみません。commitの回数つながりで、ちょっとおたずねします。

一般的にcommitって細かく（最低でも1つの機能の追加ごとに）やるものだと思うのですが、
調子に乗ってコーディングしていくうちに、手元で大量に変更してしまいました。
こういうときって、どうされていますでしょうか。

diffの出力を手作業で加工して、追加した機能（関数）もしくは変更部分ごとにパッチを作って、
それらを取り込んで→コミット...を繰り返せば何とかなると思っているのですが、
他によい方法はないでしょうか。
# 対象は1ファイルです。

408:login:Penguin
09/08/12 20:05:23 dme4v7A0
>>407
そんな時のための git add -p じゃないか

409:login:Penguin
09/08/12 20:25:02 mycJo5BE
>>408
最近それ知って、gitすげーと思った。
git add -i なんかはまだ使いこなせないが、極めたら世界が変わりそうだ。

410:login:Penguin
09/08/12 20:26:37 3jImDu3O
>大プロジェクトでも
>updateとcommitなんて日に一度くらいじゃね？

日にもよりますが１日１０回ぐらいですかね。プログラマは２０人以上
いますので全員合わせるととんでもない量の svn commit メールが来て
大変です。データサイズも200GBくらいはあるんじゃないかな。
TortoiseSVN で commit をルートディレクトリから行うと５分待ちな
状態で億劫なのでサブディレクトリからこまめにあげて上げわすれとか
出るほどのひどい状態です。

411:407
09/08/13 07:17:33 iA5oHuEp
>>408
うわ～～～。んじゃ、これは！！
すげ～～。

教えていただきありがとうございます。
今までの苦労は何だったんだって感じ...。
ほんと、gitすげーよ。

addのオプションか。diffとかpatch-formatとかみてたよ orz
っていうか、それ以外のaddのオプションもすごいのな。
なんか、今までやっていたことが「バージョン管理するための管理」みたいな
ほとんどが不毛なことって気がしてきた...。
もちっと精進するよ。
またお願いします。

412:login:Penguin
09/08/13 15:27:28 tyyaneTm
ローカル環境で git-daemon を立ち上げました。

サーバが openSUSE で、
クライアントが Windows Vista。

ローカルなので ssh なしでやりたいのですが、
どう設定すればいいでしょうか。

413:login:Penguin
09/08/13 15:44:37 zQQwCkns
まあ、色々方法はあるわな、httpとかxinetdとか
てっとりはやくやってみたそうだから、xinetdでやってみたら？
xinetd

414:login:Penguin
09/08/13 15:49:26 zQQwCkns
xinetdを起動する
xinetdにgitを登録する(gitポートにリクエストがあったとき、xinedがgit-daemonを呼び出す)
あとは、gitリポジトリ(コンテンツ)の用意と、クライアントへのgitのインストールで
クライアントから、git cloneっしょ

415:login:Penguin
09/08/13 15:57:01 tyyaneTm
>>413-414
ありがとうございます。
xinetd、挑戦してみます。

416:login:Penguin
09/08/13 16:30:15 F9EvWFzj
>>412
>>343-354

417:412
09/08/13 16:48:16 tyyaneTm
>>416
躓いて見てみたらｗ
ありがとうございます。

私も openSUSE をサーバに、
複数人で開発したい用途。

そして、どうやって新規リポジトリを作ろうかと思っていたので、本当に既視感。

再度、挑戦！

418:login:Penguin
09/08/13 18:29:12 tyyaneTm
openSUSE で git-daemon を xinetd で起動しようと思っています。
( ssh を使うのが面倒なので… )

sudo zypper install git-daemon
sudo /usr/sbin/rcxinetd restart

して、ローカルの Vista から git clone するとエラーになります。

$ git clone git://example/test/test.git
fatal: read error (Software caused connection abort)

サーバの /var/log/message を見ると

git-daemon: [23646] cannot open pid file /var/run/git-daemon.pid: Permission denied

が出ています。とりあえず chown & chgrp & chmod して

ls -l /var/log/git-daemon.pid
-rw-r--r-- 1 git-daemon nogroup 6 2009-08-13 18:24 git-daemon.pid

とし、再度 git clone すると、やはりエラーになり、/var/log/message には下記エラーが出ます…。

git-daemon: [23765] cannot drop privileges

うまく動いている方、アドバイスお願いします。

419:login:Penguin
09/08/13 18:36:55 cf0vEXgI
cannot drop privileges ということなので、xinetdの設定のほうで、
git-daemonを動かす権限をsetuidを呼べる人(rootとか?)にすればい
いのかもしれない。

420:login:Penguin
09/08/13 20:51:01 Vyg2UZ2a
ありがとうございます。
setuid...
調べてみます。

421:418
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する方法や都度リモート先を変更するのは手順が煩雑になるため・・

次ページ