git スレッド

ソースコード管理を行うバージョン管理システム、git について語ろう。

あの、リーナス・トーバルズだって、バージョン管理を始めたんだ。
http://www.kernel.org/pub/software/scm/git/

git チュートリアル (バージョン 1.5.1 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html

バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/

ところで Windows ユーザはお呼びでない？
GUI でコミットできたりする？
今は犬糞自鯖の Subversion リポジトリを
TortoiseSVN でつかってるんだけどさ．

あと，Merナントカと比べてどっちがいいの？

関連スレ

Linux 板
subversion バージョン管理【サブバージョン】
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
UNIX 板
CVS 1.3
http://pc11.2ch.net/test/read.cgi/unix/1093611448/


>>1
乙。

>>1
乙。
バージョン管理システムについて語るスレから誘導されてきました

>>2
すまん、犬がLinuxを指すんだろうなーというのは感じてたんだが、
犬糞とは？

L　I　N　U　 X
　 ~~~~~~~~ ~~~

>>7
そか、それで犬糞かー
しっかしイメージわるっ

そりゃ悪いイメージを表すための言葉だもの

お前らstash使ってますか？
1.5.3から使えるようになったんだっけな、けっこう便利。

WHITESPACEのサンプルコード張るのはヤメロ

> If there are uncommitted changes in your working tree, commit them first before running git pull.
なんでやねん

愚痴っぽいヤツだな
checkout -bして逃すか、stashしてpullするのがgitのやり方
それにコンフリクトしてなきゃpullできるだろ

git-hogehoge
コマンド多すぎ！git hogehoegに統一しろよ。かなわんわ。

git-add
git-am
git-branch
git-checkout
git-clone
git-commit
git-diff
git-format-patch
git-log
git-push
git-rebase
だけ分かればなんとかなる。きっとなる。

つgit-init

>>16
git-hogehoge は git hogehoge でもいけますが？

ほれ
ttp://linux.yyz.us/git-howto.html

$ git-
zsh: do you wish to see all 144 possibilities (49 lines)?

>>19
いけるに決まってるだろアホか
そういうことがいいたいんじゃないんだよ

>>22
＞git hogehoegに統一しろよ
って書いてるけど。じゃgit-hogehogeを無くせってか？
それともコマンド減らせって？
使わなきゃいいだけじゃん。

「＠

gitいいね
いきなりこんなの作れるLinusはやっぱすげえな
彼がバス事故とかにあったらそれでLinux終了なんだろうか

>>25
作者が死んでもソースは志しあるものに引き継がれる。
彼並みのマネージスキルというとあれだけどな。

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5.4.txt

ム板からキマスタ
windows版落としてみたら、意外に普通にうごいてびっくりした

git で、svn revert に相当するコマンドは何でしょうか。
git revert filename とすると、fatal: can't find hoge.c と言われます。

>>29
書いたとたん、git reset というのを見つけてしまったorz

>>30
gitはreset、rebase、cherry-pickを使い始めると、かなり良い感じになってくると思うヨ

git revert で、checkin を簡単に取り消せると聞いて試したのですが、
なんか checkin を取り消すんじゃなくて、checkin したのと逆のパッチを適用するみたいなんですけど、
これってそういうもんでしょうか。
個人的希望としては、直前の checkin を取り消してもとの状態に戻したいだけなんですけど。

>>32
その場合はreset使うんだお

まずはチュートリアル見てみたらいいんじゃまいか
http://www8.atwiki.jp/git_jp/

>>33
あれ、git reset は commit していない checkin を取り消すものじゃないですっけ？

>>34
resetはどこにでもリセットできるよ。これがけっこうアツいんだ。
こうすれば今のブランチの１個前にリセットされる
git reset --hard HEAD^
リセットを取り消すのはたいてい出来ないので注意

まあゆっくりドキュメント詠みなって
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#fixing-mistakes

>>39
git checkoutだよ。

さて>>39に何て書けばいいんだ

>>29宛ての間違いだった…… orz

git で、svn revert に相当するコマンドは何でしょうか。

checkout

http://gihyo.jp/magazine/SD/archive/2008/200804
SD 4 月号は git 特集らしい。

Git特集きたこれ

HEADは何を表してるんですか？ブランチ名？コミット名？
チュートリアル読んでたら、なんの説明もなしに登場してくるので、教えてください。

>>43
現在作業してるブランチに対する最新のコミットのIDのエイリアス

>>44
最近HEADって大文字で書くのがちょい億劫になってきた

HEADがコミットIDでいえば何番なのかを知るにはどうしたらいいですか

>>46
git show-ref
とか
cat .git/refs/heads/master
とか
git show HEAD
とかか？

>>47
さんくす


Gitのmapページで index という用語がでてくるんですが、これは何を意味していますか？

>>48
mapページて何だか分からないが、indexはGit特有かもしれない
ワーキングコピーとリポジトリの中間に位置する場所で、
コミットする前にいったんここに保存する感じになる。
けっこう便利に使えます。
今月号のSD見てみたら？　ムズ目かもしれないけどかなり秀逸な記事ですよ。

>>49
mapページじゃなくてmanページでした。
説明ありがとうございます。
index は、RDBMSでいうところのredoログファイルみたいなもんですかね。
SDってのはSoftwareDesign誌のことでしょうか。ちょっと買ってみます。
それにしてもSoftwareDesignはタイミングよい記事を載せますね。前回のYAMLとJSONも良かった。

>>45
見て気になったんだけど、
head って 小文字で書いてるんだけど弊害あるの？

gitを最近使い始めて、便利そうな気になっています。

ただ一点気になっていること：
subversion の自分のレポジトリから svn:externals 指定で他のモジュールの
最新版を取得する使い方が多いのですが、gitのレポジトリの場合も外部のsvnを
参照する方法があるのでしょうか？

>>51
マジheadでいけんの！？　ってやってみたらいけなかたorz
GIT 1.5.5

>>52
それは、Gitから他のGitのリポジトリってこと？
それとも、Gitから他のSVNのリポジトリを参照したいってこと？
前者はできるし、後者は git-svn使えばできそう。

リモートのリポジトリにいくつかブランチがあってgit pullする
時にmaster以外にそれらのブランチのデータも一緒にとってきたい
(でも普段checkoutするのはmaster)んだけど、それってどう設定
するのが正しいの?

>>55 自己レスですが、refspecを間違っていただけでした。
ちゃんととってきてました。
よくわかりませんが
git log origin/BRANCH_FOO
と
git log BRANCH_FOO
で内容が違うようです。

>>54
Gitから他のSVNレポジトリを参照したいです。
git-svnですね。調べてみます。

>>53
普通はできないのですか…
バージョンは、cygwinのgit 1.5.4ですね。

使っているのは、
git reset --hard head
git show head
git diff head..head~5
くらいです。
検討違いのコマンドでしたら申し分けないです

>>58
windows はファイル名の大文字小文字を区別しない。
HEAD って .git/HEAD

さてさて？

>>59
なるほど

HEADって.git/HEADを差していたのですね

windowsのファイル名大文字小文字無視が原因かなとは
疑っていましたが、なぜなのかがピンときてませんでした。
ありがとうございます。

今(windowsで)は良いけど、混乱の元になりどうなので
HEADって打つようにします。

>>56
＞git log origin/BRANCH_FOO
＞と
＞git log BRANCH_FOO
＞で内容が違うようです。
そりゃorigin/BRANCH_FOOはリモートのブランチで（git commitは出来ない）
BRANCH_FOOはローカルのブランチ（git commitできる。たまたま同じ名前なだけ）
内容が違うこともあるよ。

＞リモートのリポジトリにいくつかブランチがあってgit pullする
＞時にmaster以外にそれらのブランチのデータも一緒にとってきたい
git fetch origin とかでいけると思う。

>>52
svn:externalsはgit submoduleで似たようなことが出来るみたいだけど、
git-svnでsvn:externalsを透過的に使えるワケではないし、使い勝手はだいぶ違うようです。

>>60
逆に小文字でheadでいけるのが少し羨ましかったり。。。

>>62
どーしてもっつーなら、シンボリックリンクでも
ためしにはってみれば。.git/headとか？

>>63
それでいけた！ (・∀・)
refs/headsをごにょごにょしなきゃダメかと思ってたんだけど、
この方法で名無しブランチでもheadでいけたよ。ありがとう！

cygwin版 git で、emacs git.elが動くpatchって、まだ存在しない？

git checkout -f branch って打とうとして
git branch -f branch って打っちゃった

これ復旧させることってできますでしょうか；；

reflog -> checkout -b branch hash
あたりじゃどう。

>>67
いけました。
ありがとうございました。

一ヶ月分の作業を失ってしまったかと かなり 涙目になってました

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5.5.1.txt

特定のブランチについてるタグだけをリストするにはどうすればいい?

gitとsvnだとどちらが使いやすい？
それと svnのレポをgitからアクセスしてコミットやらチェックアウトやらって出金の？

どちらが使いやすいかは状況次第。初心者ならsvnかな。
git-svnでgitからsvnにコミットもチェックアウトもできるが
svn:externalsやsvn:ignoreなどは対応してない。

gitに慣れてからsvnを使い始めたせいかgitの方が使いやすく感じる。

初歩的な質問でですが
git-clone でクローン作って、そこで何回かコミットして
マスタへクローンの全履歴を反映させたくないんだけれど、
どうしたらいいの？
git-push したら全履歴が反映されてしまった。

>>74
クローン元と同期しておきたいブランチを作っておいて、そこをpushすればいいんじゃないかな。
俺最先端ブランチの途中までpushしたいなら、checkout -b してそこをpushとか。

squashがあったような。

git って、リポジトリにコミットした時の元ファイルのタイムスタンプって
保存されてるの？　そのタイムスタンプでチェックアウト
できたりできる？

>>77
タイムスタンプを保存して何したいのかを言ったほうがいい。

>>77 で書いた通り、インポートした時のタイムスタンプのままチェックアウト
したいんですが。

>>79
だからタイムスタンプが復元できて何がうれしいのかな？
どのように利用したいのか目的がわからずに適当に
答えても正しい答えなのかわからないよ。

ここでもタイムスタンプ厨か。お前バージョン管理システムでも湧いてなかったか？
自分の意見押しつけんのも大概にしろ。

>>80
了解です。

>>81
＞自分の意見押しつけんのも大概にしろ

おまえ良くいる頭にウジ湧いてる決めつけ厨だろ？
誰も意見押しつけてないっつーの
出来るかどうかを聞いてるだけだろ？良い悪いは問題にしてない。
意味無いレスならするなよ

何が目的で質問してんのか明かさない>>82にも問題あると思うけどな

そうかなあ？やり方を聞いてるわけでもないし、
出来るか出来ないかを聞いてるだけなんだから、
ちょっと過剰な反応のような気がするけど。

みんな、マ板の方でうんざりしてるってだけかなｗ

俺はcp -pなんて絶対使わない
男ならcpだろ、ｊｋ

>>85
まったくだ。cp -pなんて使ってる奴は糞だ。
cpには-pを付けろだのなんだのと自分の意見を押し付けんのも大概にしろ。

>>77 されてない。
ttp://git.or.cz/gitwiki/GitFaq#head-76695e517a5f4dc371c613a14a9d88fd0523bf27

v1.5.6
http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5.6.txt

* "git branch" (and "git checkout -b") can be told to set up
branch.<name>.rebase automatically, so that later you can say "git pull"
and magically cause "git pull --rebase" to happen.

これってbranch.autosetuprebaseのことなのかな…よくわからん

>>81
世の中にはお前や俺よりバカな奴が一杯いるわけだ。

それを理解していないお前はバカだと思うが、どうだろう？

「ギット」なんだね。
ttp://jp.youtube.com/watch?v=8dhZ9BXQgc4

「ジット」だと思ってた？

.gifを岐阜と読む漏れにしたらなんともない。

co-git
なんてものもあるんだから、ギットだろう

>>93
それは cogito というラテン語を知らないと通じないかも。
いや、Cogito ergo sum. くらい常識か。

gifを岐阜と読んでる奴は何人いるんだろうか
gitをギットと読んでる奴よりジットと読んでる奴の方が多いんじゃないか

日本語としてはギットよりジットの方が自然な気がする。

>>93-94
digitは「ディギット」かい?

英単語の発音に統一感を求めてもしょーがないな。

ghoti

ghoch と書いてフィッシュと読むという話なら知っているが……
同じようなもんかな。

新スレ移行のお知らせ

バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/


夜露死苦ー

統合する必要あんのか？
別に総合スレと個別スレがあってもいいじゃん。
それとも単なる荒らし？

いや、統合とかそんなんじゃなくて、単なる挨拶回り

>>103
すまん、強制的に移動しろっていう荒らしが立てたスレかと思った。
勘違いで煽って悪かった。

>>104
ｲｲﾖｲｲﾖｰ

マルチうぜぇ。

>>103
「挨拶回り」ってどういう意味？ｗ

いや、言葉自体はもちろん知ってますが。

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5.6.2.txt
1.5.6はバグ修正多いなぁ
そのうち落ち着くかな？

svnでいうところの（というか、cvsでいう）キーワード置換はないですか？
$Id:$
とか、ソースに埋め込まれたのを変更してくれるやつです

>>109
man gitattributes |less +/ident

実際に試してみると、CVSやRCSとは違ってcommitした時に
キーワードを変更してくれないな。
$ mkdir foo
$ cd foo
$ git init
Initialized empty Git repository in .git/
$ echo '* ident' >> ./.git/info/attributes
$ echo '$Id$' > TEST
$ git add TEST
$ git commit -m TEST1 TEST
Created initial commit d1fae63: TEST
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 TEST
$ cat TEST
$Id$
$ git checkout -f
$ cat TEST
$Id: 055c8729cdcc372500a08db659c045e16c4409fb $

>>111 ありがとうございます

git-logでHEADだけ(あるいは特定のversion)だけを取り出す
書式はあるのでしょうか。一応試した限りでは
git log ${version}
とやると現在のブランチで最初から${version}までを全てリスト、
git log HEAD^..HEAD
とやるとHEADだけを取り出せるのですが、versionを二回
書かないといけないのはちょっと面倒です。

git show --summary HEAD ではどうかな？

>>114
あー、そんなコマンドがあったんですね。ありがとうございます。
git show --name-only と
hg tip -v
がだいたい似たような感じですね。

age

gitええわ ヽ(´▽｀)ﾉ
今までCVSしか使ったことなかったもんで、軽くカルチャーショックだわ。
末永く使わせてもらいますわ。

日本語ファイル名は大丈夫ですか? UTF-8に限定して使おうとは思ってますが。

>>117
どんなところが良いですか？参考にしたいので。

>>119
gitはまだ個人利用しかしてないし、他の分散型も全く使った事が
ないので、あくまでcvsとの比較なんだけど。

・使い始めるまでが拍子抜けするぐらい簡単
・ブランチの扱いもすっげー簡単
・ワーキングディレクトリ下にデータベースができるのも管理が楽
・ファイルのリネームもできる

多分、これぐらいはgitでなくてもいいんだろうけど、EmacsのVCが
対応してたので使ってみた。
当然、分散型のメリットも計り知れないと思うけどまだ実感できず。
(メリットは十分理解はしてはいるよ )

cvsからの移行だとコマンド体系が似ているのでmercurialの
ほうが(最初の時点では)楽だと思う。
gitで好きなのはsharedなリポジトリを作れることかな。
cloneした時のディスク消費量が小さくて済む。

>>121
RCS,CVS->svn->hgって来てる。
gitも使っているけど、hgの方が好み。
ローカルレポジトリでの使用でもgit/hgは便利だと思う。

>>120
> ・ワーキングディレクトリ下にデータベースができるのも管理が楽

これってRCS/CVSもそうじゃないっけ?
svnは違うけど。

>>122
CVSは違うな

gitってCVSより遅いんだね
cvs updateでぶっ壊れて止まることはなくなったけどションボリだよ

>>124
そんなことはないと思うが。Windowsで使ってるとか？

cvs -z3 -d:pserver:[email protected]:/sources/emacs co emacs-cvs 2.70s user 2.19s system 3% cpu 2:11.01 total
git clone git://git.sv.gnu.org/emacs.git emacs-git 187.51s user 5.78s system 22% cpu 14:19.61 total

du emacs-cvs|tail -n 1
107M emacs-cvs
du emacs-git|tail -n 1
241M emacs-git

まるごとcheckoutするのが遅いだけでしたねごめんなすって

>>126
そりゃそうだw
CVSリポジトリをrsyncでとってきてそこからcheckoutする時間と
比べれば公平になるんじゃないかな。

はじめてgit使った時に手始めにlinux kernelをcloneしたんだが、
まるごと履歴取ってきてるのにあの時間で終わるのはすげーと思った。

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.6.0.txt

gitでlogを取る方法が分からない
具体的には
git log git://git.videolan.org/x264.git

で svn log svn://ほにゃらら
と似たような結果になると思ったが

fatal: Not a git repository

となる・・
一度cloneで取り込んでgit-logすると直近の変更点は表示されるが、全ての変更点は見られない。
gitは考え方がsvnと根本的に違うみたいでよくわからない。

commit 5dc0aae2f900064d1f58579929a2285ab289a436
Author: Laurent Aimar <[email protected]>
Date: Thu Jun 3 19:29:33 2004 +0000

* all: re-import of the CVS.


git-svn-id: svn://svn.videolan.org/x264/trunk@1 df754926-b1dd-0310-bc7b-ec298dee348c

.cvsignore | 3 +
AUTHORS | 35 +
COPYING | 340 +++++
Jamfile | 67 +
Makefile | 58 +
Makefile.cygwin | 52 +
TODO | 65 +
build/cygwin/Makefile | 102 ++
build/win32/libx264.dsp | 742 +++++++++
ry
結構昔まで見えるようだが。
svnでcvsから取り込んだときにログはドロップしてるのか分からないけどここから。

gitにsvn st -u相当の動作をさせるにはどうすればいいですか？

>>132
git help

The Git User's Survey 2008
http://www.survs.com/survey?id=M3PIVU72&channel=2WXE4BVTW8

せっかくの分散管理なのに、pushしたら自分の変更内容とかログが全部あがって
恥ずかしい思いをしたよ。
最初の変数がかなりマニアックだったとか、コメントに入れてた人生の悩みとかばれまくり。

で聞きたいんだが、手元でがしがし変更→commitしている場合、その途中ってみんなどうしてるの?
ぜんぶpush?
なんかいい方法あったら教えて。

push用のブランチ作って置くんでは？
やったことないけど
これなら公開できると思ったらpush用ブランチに
merge?マージだと履歴も逝ってしまうっけ？

つーかコメントに余計なこと書くなよ。

古いchangesetの最初の方を掃除することは可能でしょうか。
いまファイルサーバ上のツリーを記録するためにmercurialを
使っているんですが、mercurialにはそういう機能はないので
(MQ用のコマンドstripはあるがそれは直近の数changesetを
消すもの)結局移し替えのためのスクリプトを書いて対応しました。
gitにそういう機能があればhg->git移行するんですが...

>>138
Mercurialでもqimport→qfold→qdeleteでできるよ。
めんどくさいけど。

>>139
$ hg qimport -r 1
abort: revision 1 has unmanaged children

>>140
$ hg qimport -r 1:tip
$ hg qgoto 1.diff
$ hg qfold 2.diff 3.diff
$ hg qpush -a
$ hg qdelete -r qbase:qtip

スマン、ここgitスレか。
スレ違いだったな。

>>142
なるほど、勉強になりました。バイナリファイルが混じってる
時は--gitがないとえらいことになる、というのも分かりました。

ところでgitだったらそういう操作は可能でしょうか。

git remote add bob /home/bob/myrepo
で作った「bob」を/home/bob/myrepo2に変更したいんだけど
どうすればいいの？

一旦消して追加しなおす?
ローカルでリモート使ったことないけど、、、
リモートの概念は自分のワーキングコピーからアクセスできるprefixを
簡単に使うことができるようにする為のもの、と理解してるんだけど。

remote -dとかで消せるかな
試してないけど

git clone で例えば　home/red/blue/yellow と取ってきたとして、
加えて git checkout origin/colors でブランチ "colors"に居ますと。

その後の作業で、いくつかのディレクトリでブランチをmaster/colorと切り替えてたんですが、
全ディレクトリのブランチを一気にmasterにする方法ってありますか？

git introduction, yugui Ustream.TV: git introduction rails meeting @ tokyo.
http://www.ustream.tv/recorded/746377

git age .

ttp://d.hatena.ne.jp/kinneko/20081004/p4

git

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.6.0.3.txt

addしたファイルの一部を、あ〜これ別の修正だなーと思ってcancelしたいん
だけど、どうすればいいかわかりますか？

checkoutすると修正差分消えちゃうし、stashの部分的versionがあれば
いいのかもしれませんが。

まぁ、diff取って手patchでもいいので、今回はそれでやりますが、
後学のために教えてください。

>>153
git reset

>154
ありがとうございます

>>153
それよくあるわー
あるファイルをいじってる最中に関係ないバグなんかを見つけて、
つい流れでそのままやっちゃうんだよね。
でもコミットする時には別々にしたくなる．．．
俺の場合、修正が少ない時は、エディタでundo出来るようにしつつ２回に分けてコミット、
修正が複数ファイルだったり込み入ってる時は、stash使ったりdiff出して後からpatchしたりしてるな。

http://sourceforge.jp/forum/forum.php?forum_id=16362

gitはじまったな。hgとの戦いもこれで決着したか？

本家 sf.net はまだ git をサポートしてないよね。
この点では sf.jp が先行しているんだ。

tortoiseが無いから決着無理でしょ。

あるコミットの親コミットのidはgit log -1 foo^1とかでわかるんだけど、
あるコミットの子コミット一覧をなるべく高速に得る方法ってある？

>>159
ほんとはこういうプリミティブな分野ほど保守的なはずだけど
svn が出てからと言うもの乱世になっちゃった感があるね。
そう言う意味では svn の功績も大きいかも。
そんな中で日本は一般の追従が早かったりするのかな？
ただ sf.jp が勇み足ってこともあるかもしれないけどw

>>161
原理的に無理なんじゃないの？
コミットすると、その親のレポジトリに通達する仕組みが無いと

>>163
mercurialには`hg children'っていうコマンド(extension)が
あるけど、そういう機能のことじゃない?

カーネルにおけるリグレッションの特定/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_d748.html

「git add .」の時にemacsのバックアップファイル（hogehoge~）を含まないようにするのはどうすればいい？

>>166
.gitignoreに「*~」って書いとく
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#ignoring-files

fast-forwardって「早送り」って意味だよな... > wiki

>>167
ignoreあったのか、�dくす

http://code.google.com/p/tortoisegit/

>>170
wktk

質問なのですが

svnでいうチェックアウト（svn co）はgit cloneで合ってますか？
gitではユーザ名を登録しますが、ここで登録したユーザ名を頼りにチェックアウトできますか？

自分で調べた内容は、　http://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html　を見て
「共同開発における git の利用」で　git clone /home/alice/project myrepo　ってコマンドを探せたくらいです

>>172
git cheat sheet でググレカス

現在mercurialでwebデータのスナップショットをとっています。
ignoreファイルで管理対象にしたくないファイルのパターンを
指定してhg commit -A すると、消えたファイルは削除扱い、
新しいファイルは追加扱いでうまくやってくれるんですが、これを
gitでやるにはgit statusの出力をスクリプトで処理するしかない
でしょうか。

add .
commit -a
でいいのかな?

1.6.1ｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( 　ﾟ)━(　　)━(　　)━(ﾟ 　)━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!

>>176
ほんとだ。
http://git.or.cz/ にはまだ出てないけど、Tagは昨日打たれてるんだね。
さっそくビルドしてみよっと。

クリスマスプレゼントきてたか。
俺もビルドしてIYH!!

は？

どーもくんｗｗｗｗｗ

そういやGit、ドーモくんパクってるな。
なんかみたことあるなーとは思てたけど。

きっと、ライセンス問題に業を煮やしたリーナスが
新キャラクタを一から作り始めると見た

で新キャラのライセンスもGPLなんかな。
世界中で使われまくりんぐ

とりあえず年末にやっていたどーもくんテレビシリーズは面白かった。

git-cloneをしてもエラーが出てできません。どなたかお助けください。

環境
Ubuntu_1 こいつに"mysite"リポジトリがある（git init で作ったリポジトリ）
Ubuntu_2 こいつにgit-cloneをさせたい

Ubuntu_02でコマンド
:git clone ssh://name@Ubuntu_01/home/name/git/mysite/

で結果がこうなる
remote: Counting objects: 366, done.
remote: Compressing objects: 100% (150/150), done.
remote: Total 366 (delta 262), reused 296 (delta 213)
Receiving objects: 100% (366/366), 53.82 KiB, done.
Resolving deltas: 100% (262/262), done.
error: Trying to write ref HEAD with nonexistant object 73f8...（省略）
fatal: Cannot update the ref 'HEAD'.

このようなエラーが出て、mysiteフォルダが作成されませんでした。
Ubuntu_1のHEADのハッシュは73f8...です。

不思議なのが、nonexistant（nonexistentの間違い？　存在しない）といわれても、Ubuntu_1側でlogを見ても内容はあるように思えるのですが。謎です。
どなたか解決方法をご存知ありませんか。よろしくお願いします。

OSとgitのバージョンを書き忘れていました。すいません
Ubuntu_1（Ubuntu8.04.1） : git version 1.5.4.3
Ubuntu_2（Ubuntu8.10）: git version 1.5.6.3

です。gitの最新では問題ないとか、そういうものなんでしょうか・・・

--no-checkoutでやってみたらどうなる…?

こないだネカフェで漫画読んでたら、隣の席の人がマック取り出してなんかやり始めた。
しばらくたってチラ見したら、Gitチートシート見ながら使い方勉強してるようだった。
emacsでメモ取りながら。
Railsのおかげか？マックの人にも浸透してきてんだねー

gitを使うような開発者がマックを選ぶようになったというほうが近いかと

そのおかげかどうか知らんが、Rubyの開発もsvnからgitに移行しろと
ぎゃーぎゃー騒ぐ連中がrubyのMLでノイズをまき散らしている(た)

まぁ、そうしょっちゅう変更されても困るけどな。

未だにCVS使ってるプロジェクトがあることを考えると、
まぁSVNへの移行はそれなりに適切だったよな。

すれ違いスマソ

最近人気のVCSって大体リポジトリの相互変換機能があるんで
svnだからどうとかgitだからどうとかってあまり問題ないん
じゃないかと思うんだけど... 騒いでるのって実際自分では開発
してる人なのかな?

>>192
クライアントだけみても結構違いはあるよ

というか、むしろリポジトリ変換できるからどれでもいいだろと言う人の方が
自分で開発してるのか疑わしい

>>189
漏れもmac使いだけど、多い日には８割ぐらいX11で作業してるなぁ
linux板で言うことじゃないけど、最強のunix osだと思ってる

ギャグ?
目悪くなるよ、あれ。

macbook air使ってる人見たことあるけど、
パワポの起動に数十秒かかっててわろた。

AirはAppleへのお布施だってばっちゃが言ってた

Windowsは目に優しいのにな

Windows -> MSゴシック代
OSX -> ヒラギノ代

>>193
>クライアントだけみても結構違いはあるよ
違いがないとは書いてないよ。問題がないとは書いたけど。

>というか、むしろリポジトリ変換できるからどれでもいいだろと
>言う人の方が自分で開発してるのか疑わしい
なんでそこで「言う人の方が」とか出てくるんだろう...
リポジトリ変換の手段があれば普段の開発は最も自分に都合がよい
VCSを使える。プロジェクトのリポジトリを移行するのは単なる変換
以外のエネルギーが必要なんだよ(commitlogとかリポジトリのミラーとか
開発支援のためのスクリプトやドキュメントの修正とか)。その労力や
時間は開発にまわしたほうが合理的。

>>200
相互変換つっても、git-svn使ってるけどかなり寂しい状態だからなぁ…
使ったことないけどhgやbzrとならいい感じにやり取り出来るんだろうか。

git-svnはたまにclone中にSEGVることがあってちょっと困る。
どうも変換できないパターンが存在するらしいのだが、詳細が不明。

>>202
gentoo user なら、

Per Gentoo bugs #223747, #238586, when subversion is built
with USE=dso, there may be weird crashes in git-svn. You
have been warned.

って、message がデルよ。

>>203
Debianだけど、もしかしたら同じかもしれない。豚々。

git使いたいけどまわりにCVSしか使ったことないのがいるので、
まずはsvnに移行したよ。
自分自身は、git-svnつこてる。

CVSから一足飛びにgitを使ってもらうのは、酷かなと

cvs を理解して使えてるなら、git ぐらいすぐに使えるようになると思うけど。

そうか？
CVSは難しいからね。
A: CVS使い
B: CVS,SVN両使い
C: CVSは忘れたSVN使い、gitは少し

こんなメンバーで開発してるんだが、
A、Bにpush,pullを教える自身がなかったというか
Cも共同開発系操作は怪しかったので

svnになってしまった。ちょっとチキンだったか

gitをしばらく使ってみて、リモートリポジトリを用意することになりました。

ローカルA
ローカルB
リモートリポジトリ

とありまして、ローカルAにmaster、v0.1の二つのブランチがあります。

ローカルAからリモートには、push --allですべてのブランチをリモートにおきましたが、
ローカルBからリモートへのpullはmasterしか行えない気がしますが、どうなんでしょうか。
理想は、リモートを通してすべてのローカルリポジトリにブランチの共有を行いたいのですが、どんな操作方法があるでしょうか？
よろしくお願いします。

>>208
話がいまいち飲み込めないんだけど、
そのリモートをcloneじゃダメなん？

>>209
ああそうか、cloneのことを忘れていました。ありがとうございます。

>>210
cloneというか、git remote add でいつでもリモートの追加は可能だよ。
権限に問題がなければ、remoteにpushすることもできる。

cvsやsvnにはwindowsで使えるクライアントがあるから・・・

全部emacsから使えるが何か？

>>212
tortoisegitdozo-

>>207
ブランチの扱い考えると CVS な人は SVN より GIT の方が
なじみ易いんでは？

確かにsvnはリビジョンがブランチも本流も共通だったり、
気持ちわるいところはある

こないだ久々にCVS使おうとしたらさっぱりワケワカんなくなってたよ…
CVSのブランチってファイル毎じゃなかったっけ。今となってはもう無理な気がする。

>>216
それがsubversionのいいところ。
たとえばあるブランチの開発がすすんでそっちを本流にしたくなった場合、
trunkにマージするという断絶ではなく
本流を切り替えるという操作がそのままできる。

>>218
それ気持ち悪い
ブランチ担当者が1ファイル毎にcommitするとか、
コンパイルも通らないソースcommitしてくれたりして、
怪しいリビジョンが増えんだよね。svn

gitだったらブランチ替えるのもrebaseすれば
問題ない

>>219
使い方が悪い場合にツールに文句付けても仕方ないな。

>>218 のようなケースは分散型ではそれこそ
「本流にしたくなったブランチを本流とみなす」
だけになるのではなかろうか。

本来のmasterブランチを別名に改名して別のブランチをmasterに改名すればいんじゃね？

すみません、教えてください。
git pull したときに、一部のファイルだけ、自分の修正を破棄してリモートのファイルをそのまま適用することは
できないのでしょうか?
SVNで、updateしてコンフリクトした時の tf みたいなイメージです。

git reset?

あー、いや、そういうんじゃなくて、ソフトの翻訳をしていて、ja.poだけは自分で修正するんですが、
make update-poとかすると、他の言語のpoファイルも更新されてしまいます。
それやっちったあとにリモート側でpoファイルが更新されるとカオスになります。
なので、コンフリクトした時にマージとかしないで、リモート側(かローカル側かどっちか)を採用みたい
なのができないかなと。

>>220
gitだったら、自分専用になるから他のブランチのcommitポリシー
関係なくなるじゃん。
まともになったらpullしてやんよと言うだけで、
教育する手間がいらんということだ。

>>223
git mergeのドキュメントを--strategyあたりでgrepすると良いと思う。
git pull = git fetch + git mergeね。

>>225
>make update-poとかすると、他の言語のpoファイルも更新されてしまいます。
他の言語のpoファイルを更新しないようにMakefileを修正する。

>>223
http://gitready.com/advanced/2009/02/25/keep-either-file-in-merge-conflicts.html
タイムリーなtipsが

>>223
もどしたいファイルはcheckoutすればいいだけじゃね？
あとは自分の修正はstashするとか色々

FTPに1.6.2正式版来ました

git-cloneとgit-remote addとgit-svnを使い分けてると

　このフォルダで更新するためのコマンドなんだっけ？

とミスることが多発するんだけど、こういうのって同じコマンドで
管理できないんでしょうか？今は

- git-clone の場合 -> git-pull で更新
- git-remote の場合 -> git-remote update で更新
- git-svn の場合 -> git-svn update で更新

とバラバラで、しかもlsしただけでは判定できないしで
誤実行しては.git/config調べて「ああそうだった」の連発です。

もしかしてもっと便利な統合コマンドがあったりするでしょうか？

それぞれ役割が違うだろうに。
あと更新とかじゃないよ。

他の人のリポジトリからチェンジセットを引っ張ってくるために打つコマンドという
意味で同じように使っているのですが、もしかしてこの使い方・理解自体が
間違ってるんでしょうか？

>>232
いずれの場合も更新のためのシェルスクリプトを書いとけば
悩む必要がなくなるよね。
でgit-pullはfetch+merge --ff、git-remote updateはgit fetchと
ほぼ同じなんで役割が違う。git-remote addで追加したremoteだと
git-pullで更新してくれない、というのであればそれはローカル
ブランチの設定が正しくできていない、refspecの設定が変、とか
そんなところだと思う。
git-fetchでなくgit-remote updateをあえて使う利点はremoteを
複数設定している時にいっぺんに更新できることぐらいかな
(このあたりの動作はgit-remote(1)のupdateのところに書いてある)

darcsから乗り換えるといいことありますか？

>>236
pull したときに、いっぱい　yes/no 聞かれずにすむ。

hg から乗り換えるといいことありますか?

>238

まーきゅりある、って難しいスペルを覚えなくても良くなる。
覚えてないけど。

>>238
高速.

git svn clone -s で Subversion からレポジトリをコピーしてみたのですが、
Subversion の tags が Git の tag にならずに branch になってしまうのは、
そういうものなのでしょうか。

Subversion のタグは、タグといいながらただのディレクトリだったりする変態仕様なので、
しょうがないのかなぁ…という気もするのですが…。

社内の git リポジトリを表示するのを探してます。
( github が許されなくて… )

Git Browser と ViewGit を見つけました。

Git Browser は見た目派手だけど実用度に疑問なので
ViewGit を検討しています。

ほかに何かいいのありませんか。
github クローンがあれば最高です。

>>242
ttp://git.or.cz/gitwiki/InterfacesFrontendsAndTools

おお、こんなにあったんですね。ありがとうございます。

うーん、ざっと見た限り GitHub や ViewVC レベルってないですね。
定番はデフォルトの gitweb なのかな？

>>242
微妙に違うかもしれないけど
redmineに付属のリポジトリブラウザなんてどうよ？

>>245
ありがとうございます。
trac & redmine は使ってます。
チケットとコミットを連動させるために。

差分のリッチな diff や、フォークの流れ、パッチ管理が
github を知ってしまうと、どれも霞んで見えて。。。

linux関係者はgitを使うのが多いという認識でいいのかな

linux 開発者は git しか使わないだろ常考

>>247
Linux(狭義の=カーネルそのもの)開発のために作られたのがgit

ＧｉｔＨｕｂでソース管理している人に聞きたいんですけど、
プロジェクトのホームページやリリース物件置き場やITSってどこつかってます？

>>250
>プロジェクトのホームページ
githubでホストできる

>リリース物件置き場
適当にタグ付けしておけばzip等でダウンロードできるようになってる

>ITS
>>252に任せた

checkpadかRTMでおk(マテ

>>246
GithubのUIってそんないいかなーあんま好きじゃない。。。
俺は普通にGitwebがいちばん分かりやすいと思う。
じっくり見るならCUIだけど。git show-branchとかけっこう分かりやすいと思うな。

>>250
ditzがいいと思います

>> 250
lighthouseじゃだめ(´・ω・`)？
もしくは、ticgit。

xrea に入れてる人って自前でコンパイルしてるのかな。
うちは面倒になったやめてmercurialをいれてgitweb形式で
使ってるわ。インストールはこっちのほうが簡単だったから。
xrea用のバイナリを公開しているところがあればなぁ。(ぶつぶつぶつぶつ)

xreaでgit入れられるの？makeでリソース不足になるかと思っていた。

>>257
いれてる人はいるみたい。

xreaに自前で入れるっていう人は、ホスティングじゃ嫌な理由があるのん？

>>259
githubってプライベートリポジトリが作れないし。そのへんじゃないのか。
容量も桁ちがいになるって事実もある。それは大きくないか。

>>257
サーバーでmakeをやってるんだろうか？てっきりクロスコンパイルかなにかだと思った。

>>260
「タダでは」作れない、と一応補足。

>>260
XREAにコンパイラはなかったと思う。クロスコンパイルしてるんでしょう

クロスってわざわざx86以外でコンパイルするんかいw
パッケージ作って持ち込んだらいいんちゃう？

xreaにgit入れてみたいけど、
違う環境でコンパイルしたものを持ち込むのって
やってみたことないなぁ

>>263
それも試した。そのためにはosの環境を知るひつようがあるが。

>>264
mercurialは簡単に入ったけど、どうしてもgitとなれば、git-mercurialを使うか
svn-gitを使うかって方法もあるよ。svnは入ってるから。

gitを導入できそうなのに、OSが不明ってどういうことなんだ？
xrea昔使ってたけどわすれちゃったい

>>267
サーバーで違うからね。

githubのIssueって使えてる?
どのrepoをみても、ず〜っと「Loading」のままなんだけど‥‥‥。(´Д`)

issues(0)のものならLoadingにはならなかった。
10個ぐらい探したけどissues(0)でないものは見つからなかった。
Safari4Beta

WEB+DB PRESS vol.50のgit特集って現メンテナの記事なんだな。

浜田さんですね

>>270
あれ？そう？
じゃあ、自分だけかぁ。
誰もどこにも不具合報告してない感じだし。
Firefox 3.0.7

javascript切ってる、とか

>>274
ありがとうございます。

javascript関係とcookie関係は(NoScriptも使っているし)真っ先に疑っていろいろ設定値を変更してみたんだけど、
変化なし。
で、今朝帰宅後に何気なくみてみたら、(再読込とかもしていないのに)Loadingが消えていたよ。
読み込みに何時間かけたんやって感じだけど、とにかくCreate Issuesボタンを押しても反応するし、
よくわからんが使えるようになったので、よしとした。
# 自分は、「動けば何でもいいや」サンデープログラマなので。

ちなみに、IEでも確かめてみたが、IE6でもIE7でもLoadingのまま。(´・ω・`)
まぁ、普段は使わないから(ry

すいません、2つ質問したいことがあります。

branchとdiffには --color オプションがあるのに、statusだけ無いので、
これだけ

[color]
status = auto

と指定しなければいけないのを避けたくて、出来ればstatus --colorなどしたいのですが、可能ですか？

また、svnでいうリビジョン指定のupdate、たとえば svn up -r4などをしたいのですが、
revertを使うと勝手にコミットされてしまいます。コミットせずに、ただリビジョンを戻したいときはどのコマンドを使えばいいですか？

>> 276
∩(　´Α`)<　276、「git config --global ui.color auto」ってどうよ？

2個目のは
git checkout 〜
かな？
# よくわからんが。

>>277
ありがとうございます。
＞git config --global ui.color auto
centos4.2 / git 1.5.2.1 で効かない模様です・・

2個目は、例えばsvnで、リビジョン5が最新だとして、リビジョン5の時点で、「svn up -r3」と打つと、リソースがリビジョン3の時点のものになるのです。
その後「svn up」と打てば、リビジョン5に戻ります。
gitの場合、「git revert コミット時のハッシュ」で、前回のコミット時の状態に戻すことが出来ますが、revertは「前回との差分を反映した上でコミットする」ようなのです。
以前の状態に戻してもらえれば、別にコミットしなくてもいいのですが、そういうことをしてくれるコマンドを探しています。

>>278
git checkout {commit} -- .

git reset使っても良いけどreflog変わっちゃうから私はお勧めしない。

二つ前だったら
git checkout HEAD^^
とか書けるのがいいやね

git help svnなどでヘルプが見られるはずなのに、No manual entry for git-svnとしか出ません。
バージョンによってヘルプが無かったりするんでしょうか・・？

make man してないってオチじゃなくて?

>>282
cdとかlsのmanはあります。
centos5.1で、gitはyumでインストールして、バージョンは1.5.2.1です。

>>283
じゃあドキュメントは別のパッケージになってるとか。

試してないけどgit-svnパッケージを入れないとコマンド自体無いよね。

面倒だからgitで最新版落としてコンパイルしてインストールしたら?

1.6.3出たぞ

1.6.3.1

キーを作って、

Enter file in which to save the key
(/c/Documents and Settings/Administrator/.ssh/id_rsa):


ってメッセージが出るのですが、
該当のディレクトリを探しても、

/.ssh/id_rsa):

が存在しません。

どこにいったのでしょうか？

>>289

まだない。
その文の訳は「鍵を保存するファイルを入力してね」だ。
カッコ内は、名前を指定しなかったときにこの名前になるよってこと。

んじゃあ、ENTERを押せばよかったってこと？

そゆこと

git clean -fx したときにでも特定の虫ファイルが生き残るようにする設定ないかなあ。

>>293
まさかGitリポジトリの中で虫を飼ってるやつがいるとは・・・。
はっ！なるほど、バグを飼ってるんですね、わか(ry

そうそう、鈴虫だけは駆除したk…ってのはおいといて。
設定ファイルをgitで管理してて、
パスワードとかはいっててリポジトリに入れるのはなんかいやなファイルがあるんだけど、
git clean -fxとかしちゃうとそれまで消えちゃうんだよね。
makeの.PRECIOUSみたいな設定ができると嬉しい。
まあ需要なさそうだよな…

>>295
何の設定ファイルか知らないけど、そういう場所でclean -fx
するのはそもそも間違いじゃないの?

まあね。そうなんだけど。
でもauthorized_keys~とか消したくね？ね？

うだうだ言ってないで、自分で改造しろよ

俺なら、レポジトリの外においとくけどなぁ > 設定ファイル

色んなところの設定をリポジトリに突っ込んで管理してるのです。
>>298の言うとおり、そのうち改造してみることにします。

clean -f じゃだめなの？

まあそういう解もあるけど。
でも、hogehoge~とかがUntracked filesと表示されるのはいや。

>>302
.gitignore で除外指定するのも手かと。

>>302
普通にcleanしてもhogehoge~とか消えないの？
hogehogeがignoreされてるの？

つまりですね、.gitignoreされているhogehoge~を消したいが、
.gitignoreで一緒に除外されているid_rsaとかは消したくない、と。
そういうことです。
git config clean.precious とかで設定できるようにしようかと思っている。

git cleanを使わない。

ownershipを自分以外にしておく(対症療法...)

聞いてくるのはディレクトリのuidな罠

>>305
なるほどねぇ…俺はset nobackupなんで全く気にならなかった。
PRECIOUSいいかもねー。
末尾~のファイルを一括削除するタスク作るのが手っ取り早いような気もするが。。。

それだけのためにMakefileを書くのもどうも。

自分は.bashrcで
　　alias rmtilde='rm -f *~ .*~'
としておいて rmtilde と打てばカレントディレクトリのバックアップファイルが消えるようにしている

毎度 rm *~ と打ってるとミスってファイル全消しとかやりそうで怖いからこうした

バックアップファイルは、別の場所に保存するようにすれば？

gitコマンドで見えないものは、気にしない。

見えないからこそ、ついgit clean -fxってやっちゃいそうで怖い。
-fつけるな、っていう反論は尤もだけど。

実際clean -fdx するのはGitをビルドする時ぐらいかなぁ。
make cleanで良いだろうとは思うんだけど。

あとコーディングしてるとUntracked filesがどんどん増えていってしまう
性分なので、気軽にcleanはできない…。

>>311
シェルでワイルドカード使うときはC-x * で展開してから実行するだろ

>>314
>>306

>>316
いや？

>>316
rootで作業するときは
echo rm *~ みたいなことをして確認している。

俺もalias作ってるな

debian系ならtrash-cliパッケージをインストールして、
alias rm trash
見たいなのを.bashrcに書いとけば、Windows見たいなゴミ箱のシステムが使える。
これでいざというときも安心。

>>321
trash-cliなんて便利そうなの知らなかったよ、あんがと。

そしてそれが入ってないシステムでいつもの癖が出て悶絶するw

>>323
trashコマンドはオプションがないので、rm -rf *とかしなくてもrm *でいい。
だから、rm *と打つ癖を付けとけばtrashがない環境でも削除するかダイアログで聞かれるはず。

どっちかというとそういう小細工するよりはちゃんとバックアップとっといた
ほうがいい気がする。>>323みたいなのはあるし。

俺は、~/以下のファイルを/home/$USER.bk以下にぜんぶハードリンクする
スクリプト書いてバックアップにしてる。
zshつかってるのにrm * したんだよね……

スレチ・ガイ登場の予感

>>293 わかったよ。.gitignoreとは別の除外リストがあるらしい。 $ git help repository-layout |less +/exclude

ttp://github.com/yhara/sinatbbs/tree/magazine
これをcloneしたいんですが、表示されているclone urlでcloneすると
ttp://github.com/yhara/sinatbbs/tree/master
こっちをcloneしてしまいます。
多分ブランチでmagazineが存在するんだろうと思うんですが、masterをcloneしてgit branchしてもmasterしか表示されません。
どうすればmagazineをcloneできますか？

試してないけど clone はできてるんじゃね？

リモートリポジトリの magazine ブランチで遊びたいなら、
git checkout -b magazine origin/magazine とかしてみたらどう？

リモートリポジトリのブランチは git branch -r で確認できると思うよ。

>>329
git clone git://github.com/yhara/sinatbbs.git magazine

じゃない?

$ URL=git://github.com/yhara/sinatbbs.git
$ git clone -n $URL
$ git checkout -b magazine origin/magazine

magazine以外取ってきたくもない、という場合はこうかな。
$ mkdir sinabbs
$ cd sinabbs
$ git init
$ git remote add -t magazine origin $URL
$ git fetch
$ git checkout -b magazine origin/magazine

>>332
いけました、ありがとうございました。

1-2-3 … master
　+-a-b-c-d-e … experimental

で、 experimantal のうち a と c だけ master に適用して github に push したいです
master で experimental をマージしたら a b c d e 全部 master に入ってしまうのが困るです

>>334
>>74>>76あたり

>>334
cherry-pickが手軽だと思う

git-pushのデフォが--dry-runで、本当にpushする時だけ
--no-dry-runっていう動作にするにはソースをいじるしか
ないのかな。そういう需要ってあまりないんだろうか。

>>337
git config --global alias.p 'push --dry-run'
としてpush使わないとか

charset という名前の github の唯一のリポジトリを削除する方法は

　　git push [email protected]:USERNAME/PROJECT.git :charset

でいいよね？
charset は予約名で、作ったら絶対に消せないとかそういうのないよね

　　git push 場所 master

でも master が GitHub の USERNAME の PROJECT のページに出てこないんだけどなんだろう
ttps://github.com/USERNAME/PROJECT/tree にアクセスすると
ttps://github.com/USERNAME/PROJECT/tree/charset に飛ばされるんだが
ちなみに ttps://github.com/USERNAME/PROJECT/tree/master は 404

間違ってるかもしれないけど、github からプロジェクト消したいなら
ウェブ上のインターフェイスからできるよ。

>>339
最近のGitHubは微妙にレスポンスが悪い
pushしたら2時間くらい放置することにしてる
たぶん、今日見たら消えてると思う

質問、トライアルごとにブランチ切るような使い方してるんだけど、
一応完成して、メインストリームブランチに入れて、
倉庫みたいな物置ブランチにコピーしておいて
という使い方をすると、「もう必要ない使用済み」のちいさなブランチができるよね
これを
「"圧縮"してどこかに退けておいて git-branch で表示されないようにしておく」
ということはできない？
git branch すると20個くらいだーっと表示されてもうわけわからん状態になってるん
ブランチを消してもいいんだけど、なんか操作ミスとかでマージしたメインブランチが消えたときとかの予備にみたいな貧乏性

>>341
まったく同じだｗ
俺も貧乏性というかビビりなんでブランチやたら残ってる。
pushの際にfast forwardできた時はまだ良いんだけど、rebaseとかcherry-pickした時は
古いブランチを念のために残しちゃうんだよねぇ。
やり方としては、必要なくなったブランチがある今の場所を他からremoteで
fetchさせておいて、そっちでcheckout -bしておくとかかね…めんどくさいな。

git-daemonについて質問です。
開発用と同じPCにgit-daemonをセットアップしようとしています。
基本的にはこちらにある通りに設定を行いました。
http://d.hatena.ne.jp/amacou/20090113/1231831940
わたしの環境はgit-1.6.0.2、opensuse11.1です。

git cloneやcommitはできたのですが、
git pushを行うと以下のエラーメッセージが表示され、結局pushが行われません。
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 219 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
error: unpack failed: unpacker exited with error code
fatal: read error (Connection reset by peer)

>>1にあるマニュアルの日本語訳は見たのですが、
git-daemonについてはまだ訳されておらず、よく分かりません。
すみませんがよろしくお願いします。

上のエラーメッセージはLAN内のプライベートIPを用いてgit pushとしたときで、
127.0.0.1に対してgit cloneをした後、git pushとしたときは
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 258 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
error: unpack failed: unpacker exited with error code
To git://127.0.0.1/hobby/git_test.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'git://127.0.0.1/hobby/git_test.git'

ネットワークの設定がおかしいのかもしれません。ちなみにps aux | grep gitすると、
git-daemon --syslog --detach --reuseaddr --user=git-daemon --group=nogroup --pid-file=/var/run/git-daemon.pid --base-path=/srv/git --enable=receive-pack --export-all
というコマンドで実行されているようです。

>>343
うーん、git-daemonの書込みパーミッションとか？
git-daemonにreceivepack設定してpushさせると匿名フルオープンになるみたいなので、
sshのほうが良いんじゃないかと思う。
てかgit-daemonでpush出来るとは知らなかった…

>>345
gitを使い始めて浅いもので理解していないのですが
＞ sshのほうが良いんじゃないかと思う。
これはどういう意味でしょうか？man git-pushで
ssh://[user@]host.xz/path/to/repo.git/
という表記は見かけましたが、このコマンドでpushするべきだとことでしょうか？

書き込みパーミッションが無いことが問題だったようです。

まず、自分ユーザの権限が及ぶところにbareレポジトリ(~/repos/git_test)を作ってみたら
$ git clone ssh://127.0.0.1/~/repos/git_test
は出来ました。そこに編集後、$ git pushすることもできました。

>>344のプロセスにあるように、
git-daemonはgit-daemonユーザ権限で実行されているのですが、
git-daemonユーザが/srv/git以下に書き込み権限がないことが理由だったようです。
レポジトリ以下のファイルをgit-daemonユーザにchownしたら、
git push git://....ができるようになりました。

ところで、gitレポジトリに書き込み権限のあるユーザに
新しいレポジトリを作ってもらうようなコマンドって存在しますでしょうか？
例えばですが、git create git://host.xz/path/to/repo.git/
を発行すると、新しくrepo.gitというレポジトリを作ってもらうようなものです。

>>346
このへん参考になるかも
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/user-manual.html#pushing-changes-to-a-public-repository

Gitの操作に慣れるという意味ではgit-daemonもsshも使わずに普通に同じホストで
pushとかしても大体同じなので、それでもいいと思う。
gittutorial(7)
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/gittutorial.html

LAN内少人数で中央集権の置き場として運用したいということなら、
git-daemonで匿名pushOKにしてやっても良いかもしれないですが。

sshでpushはさせたいけどシェルは使わせたくないとか、本格的にGitを
ホスティングしたいのであれば、Gitosisが便利ですよ。

>>347
＞例えばですが、git create git://host.xz/path/to/repo.git/
＞を発行すると、新しくrepo.gitというレポジトリを作ってもらうようなものです。
よくわからないけど、あったっけなぁ。ブランチを作るのはできるけど。。。
sshできるならそこのホストにログインしてgit initすれば出来る。
それか管理者が作っておいてあげるとか。
Gitosisはそのへんの管理が柔軟にできるようにはなってましたが。

Windows に cygwin 入れて使ってます。
ls ~ して出るところに .gitignore を置いているのですが、
git status すると、ignore 指定したファイルが

# Untracked files:
# (use "git add <file>..." to include in what will be committed)

に出てきます。どのように設定すればよいでしょうか。

>>350
git config [--global] core.exludesfile ~/.gitignore

>>351
ありがとうございます。
それでも変わらず…。

>>352
core.excludesfile だよん

>>348
お返事ありがとうございます。

＞ Gitの操作に慣れるという意味ではgit-daemonもsshも使わずに普通に同じホストで
＞ pushとかしても大体同じなので、それでもいいと思う。
git://~~~とかssh://~~~でなくともgit clone ~/path/to/repo.git/
という感じにネットワーク越しの操作じゃなくても使えるのですね。
こういうことができるなら、
わたしの使い方ならgitデーモン立ち上げなくともよさそうです。

いただいたURL、Gitosisについても今後の為に読ませていただきます。
ありがとうございました。

linuxデスクトップユーザーの特徴

�@インストールしただけで選民思想
�Aやっていることはwindowsと同じ。しかもめんどくさくなっただけ。
�Bコマンド打ち込んでプロだと勘違い
�C黙ってwindowsでも使ってろと間口を狭める
�D素人がだのなんだのとwindowユーザーを馬鹿にする
�Eカーネルいじればいいだろと無茶を要求
�Flinux開発者とのずれを認識できていない
�Gwineを使うくせにlinuxを再現しようとする動きがあるとたたく

　　　　　　 冫─'　 ~　￣´^-、
　　　　　／　　　　　　　　　　丶
　　　　/　　　　　　　　　　　　　ﾉ、
　　　/　　／ヽ丿彡彡彡彡彡ヽヽ
　　　|　　丿　　　　　　　　　　　ミ
　　　|　彡　＿＿__　　＿＿__ 　ﾐ/
　　　ゝ_/／|　　　 |⌒|　　　 |ヽゞ
　　　|tゝ　　＼__／_　 ＼__／　| |　　　 ＿＿＿＿＿＿＿＿＿＿
　　　ヽﾉ　　　　／＼_／＼　　 |ﾉ　　／
　　　　ゝ　　　/ヽ───‐ヽ　/　　/ 　linuxはめんどくさくて難しい分だけ、
　　　　 /|ヽ　　　ヽ──'　　 /　＜　　自称プロが悦に浸るためのツールとして最高なんじゃないだろうかwww
　　　　/ | 　＼　　　￣　　／　　　＼
　 　／　ヽ　　 　‐-　　　　　　　 　　　￣￣￣￣￣￣￣￣

>>353
ありがとうございます。うまくいきました！

git status を git st にしようと

git config --global alias.st status

しました。

git status では何も変更がないのに
git st すると膨大な modified: が出ます。
( modify してないのに )

git status = git st にするにはどうしたらいいでしょうか。

BがAをcloneしているとして
B→Aにpushしたとき、warningがだだっと出て、Aではgit reset --hardしないとpushした内容になりません。
resetせずとも良いやり方はありますか？
（A→Bは操作できません）

>358
warningの内容が分からないので適当だけど、
A側に変更がある状態でpushしてるんじゃないかな。
pushする先はbareリポジトリのほうがいいよ。

>>359
Thanks!
bareリポジトリにpushすれば良いのですね
今まで勘違いしてたけど調べて分かりました

>>357
分かる方いらっしゃいませんか

>>357
俺は ~/.gitconfig にこうやって書いてるけど、全然問題なし。
[alias]
st = status

>>362
ありがと。そうか。。。
正しい git status の結果になるディレクトリと、
長大な modified が出るディレクトリがあることが分かりました。
仕方なく git status と書かれた gitst.bat を使ってます。

>>363
…もしかしてWindows？
ここLinux板だし、こっちでも聴いてみたらどうだろう。
http://pc12.2ch.net/test/read.cgi/tech/1242918130/

>>364
Windows ( cygwin ) です。
そっちで聞いてみます。ありがとうございました。

GitHub で公開されてる fork 元で、バカみたいに大規模なファイル構成とファイル内容の全変更がありました
いちおうこれに追随しなければならないんですが、
手元の適当なブランチに試しにpullしたら衝突解消がとってもめんどくさいことになって泣きました

手元にブランチが20個くらいあります。全部に対してこれを繰り返すのは嫌です
きっとなんか便利な方法があるんだとは思うんですが、何をすればいいものなんでしょうか？

>>366
WWW::Mechanize？

大量の衝突をうまくマージする方法じゃないの？
取得を自動でやる方法じゃなくて

>>368
ごめんなさい、>>367は「バカみたいに大規模なファイル構成とファイル内容の全変更」があったものについての予想です。

Ruby版の?

module WWW
 class Mechanize
 end
end
を
class Mechanize
end
# と外出しして
module WWW
 Mechanize = ::Mechanize
end
で後方互換性を保つとゆー大顰蹙。

# nbsp の使い方はこれであってるのだろうか

うぉーなんだそれは…

論理構造的にはともかく、diffの各行的には単にインデントが浅くなっただけじゃん
module WWW と end のとこだけだろ、それ引っかかるの

>>366
git rerere --help

GitHubに試しに登録してpushまで終わったんだが、
検索にかからない、自分のIDすらかからない・・・なんだこりゃ

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

git commit したら自動で -v オプションを付ける方法はなんでしょうか

>>376
aliasを設定するとか。

1.6.4 age

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9
原書はどんなできなのかな？

>>379
Pragprogの原書なのでブランド買いした。

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

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

>>380
レビュー、ありがとう。
この訳本が出たら、立ち読みしてみて、考えよう。

gitとsquidを連携したwebキャッシュ作りたいんだけど
gitを改造しないでsquidと連携させることできる？

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

>>382
「連携」が何か他の人に伝わってる、と思うのはなぜ?

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

とカキコしてから気になって調べたら、
git config i18n.logOutputEncoding UTF8すると
あたらしくUTF8で書いてもしっかり全部化けずにいけますた。

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

うん、やっぱ言葉が悪いよな

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

>>387
cherry-pickしたらハッシュ変わるけどどうすんの？

たぶん、衝突するようなマージばかりを経験してるのだと思われ

公開したらrebase出来なくなって、FFできそうなやつでもmergeするしかなくなるってのは
どうにかならないもんかとたまに思うことはあるな。まあしょうがない気はするけど。

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

えーと、こっちのブランチでcherry-pickしてないのどれだっけ？
とかなる希ガス

cp はブランチ作り切った最後に行う
cp を頻繁に行う人はコミットメッセージも cp 時に有機的に書き換えてるはずなので
よっぽど変なまとめ方しない限り大丈夫

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

>>391
公開してるリポジトリに直接commitしたりとかしてんの?

>>394
いや、pushしてるよ。ただフォーク元も公開してるから。

mergeっていけないことなのか？必要悪なのか?

pushしたブランチの履歴は変更してはいけないというルールがあるからな

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

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

>>397
ハッシュ値をどうやって計算してるか知らないの?

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

resolveがある場合のgitのマージコミットって、
> 「AをしてBをしてCをする差分適用であるが、今回に限ってはBのあとにXであるさらなる差分適用がある」
におけるXになってない？

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

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

>>401
速度はたぶんものすごく早くなると思う。
ローカル側のディスク使用量はそれほど気にならないよ。

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

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

>403
今一環境がかんないんだが、大プロジェクトでも
updateとcommitなんて日に一度くらいじゃね？

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

一日最低 10 回は commit してるなぁ

commit --amend含めると30いくかな

すみません。commitの回数つながりで、ちょっとおたずねします。

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

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

>>407
そんな時のための git add -p じゃないか

>>408
最近それ知って、gitすげーと思った。
git add -i なんかはまだ使いこなせないが、極めたら世界が変わりそうだ。

>大プロジェクトでも
>updateとcommitなんて日に一度くらいじゃね？

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

>>408
うわ〜〜〜。んじゃ、これは！！
すげ〜〜。

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

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

ローカル環境で git-daemon を立ち上げました。

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

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

まあ、色々方法はあるわな、httpとかxinetdとか
てっとりはやくやってみたそうだから、xinetdでやってみたら？
xinetd

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

>>413-414
ありがとうございます。
xinetd、挑戦してみます。

>>412
>>343-354

>>416
躓いて見てみたらｗ
ありがとうございます。

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

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

再度、挑戦！

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

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

cannot drop privileges ということなので、xinetdの設定のほうで、
git-daemonを動かす権限をsetuidを呼べる人(rootとか?)にすればい
いのかもしれない。

ありがとうございます。
setuid...
調べてみます。

アドバイスを元に /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 スレで聞いた方がいいのかもしれませんが、
その前に、ここでお分かりになる方はいらっしゃいますでしょうか。

>>421
ttp://www.aoisakura.jp/tdiary/?date=20081212
おなじエラーではまってる人がいました。
以前動かそうとしていたものが正常終了していないのでは?

ありがとうございます。
プロセスを 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 を再起動してみます…。

余談。
zypper install git-daemon で作られる /etc/xinetd.d/git には

--base-path="/srv/git"

と書かれていて、" を消して

--base-path=/srv/git

としないといけなかった。
昨日からハマっているので、午前中の段階で精神的に疲労中ｗ

再起動しても

$ 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 しても自動で立ち上がります。
これを止める方法を探しますが、アドバイスがあると嬉しいです。

xinetdから起動されたgit-daemonが、リクエストを処理し終わっても
そのままデーモンとして残り続けていませんか?
xinetdから起動するなら、処理ごとに終了するべきですね。
git-daemonに渡せるオプションはありませんか?
--inetd だろうか。

>>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

あー、今日はもう帰ってビール飲みたい。

興奮して間違えましたが、429 さんではなく、>>426 さんです。
そのほか、いろいろ助言を下さった方、ありがとうございました。

read only で構わないのですが、linus 達がいじっている
linux kernel tree 本線を git で、ローカルのlinux PC 上に
同期できるでしょうか？その場合、どうすれば良いですか？

linux kernel git torvalds

でぐぐれ

ありがとうございました。逝ってきます。

>>429
>read only で構わないのですが、

コミットの適切な粒度がわからない
GitHubのNetworksでどばっと20個くらいドットが突出すると悩む
これやっぱ手作業でまとめておくべきだったかもしれない、とか

手元のコミットは細かくして公開するブランチに追加するときにまとめるのがいいのだろうか
でもコミットを1個ずつ扱うのってブランチのメリットなくね、とも思ってみたり
マージとかができてこそのブランチだろう、とも思う

>>433
何がしたいのかが分かって、適度な量の差分があって、機能単位にまとまっていれば
（混ざり合っていなければ）それでいいんじゃないかな。
後はバリバリ作り中なのか、機能追加中なのか、とか、、、
同時にコーディングしてる人の数にもよるね…
俺はキレイなコミットを作りたいほうなのでけっこうまとめてからにしてしまうなぁ

最近、なんかgitの勢いすごいね
そこら中で使われはじめて
リーナスのいうように、kernel特化でほそぼそといくと思ってたよ

hg派だったがリスク分散のため入門gitで勉強中。
微妙な違いがいやらしいなぁ。
viとemacsは同時に使えるが
hgとgitはかなり混乱しそうだ。

monotoneどうよ？

>>433
そんなレベルの人間が公開なんかするな
迷惑だから

　　　　　　　　　　　　　　 .| 　
　　　　　　　　　　　　　　 .| 　
　　 　∩＿＿＿∩　　　　| 　
　　　 | ノ＼　　 ,＿ ヽ　　.| 　
　　　/　　●゛　　● | 　 .J 　
　　 |　∪　　( _●_)　ミ　
　　彡､　　　|∪|　　 |　　　　　
　/　　　　 ∩ノ ⊃　 ヽ
　(　 ＼　／ ＿ノ　|　 |
　 ＼　 "　 ／　　｜　|
　　　＼ ／￣￣￣ ／

git push した時に表示される、

Total 15 (delta 13), reused 0 (delta 0)

の delta や reused って何でしょうか？

git を使い始めて、また git 関連の文書を読んでて気になった点。

・index, cached, stage といった用語を一貫して欲しい
・obj, ref などが何の説明もなく頻繁に登場するが、何を指しているのか不明

>>441
>index, cached, stage といった用語を一貫して欲しい
MLしばらく読んでからパッチ送る、とか。
>obj,ref
git help tutorial-2
あたりかな?

>>441
> ・index, cached, stage といった用語を一貫して欲しい
無理。indexで統一できなくはないけど、どういう使い方をしているかで呼び分けてるから。
ML漁ればどういう意図で呼び分けてるかの回答はあるよ。

それじゃダメだろふつー
用語集はつけとくべきだな

stageは利用者側の視点。
indexは実装者側の視点。
cacheはどういう発想なのか不思議。

用語集も見つけられないの? 何なの?
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#glossary

>446
cache Obsolete for: index.
えらそうなこった

ところで
> Truth be told, it can also contain a second, and even a third version of a working tree
これHamanoさんか誰かの講演を聞いた人のメモで読んだことが
あるのを思いだしたんだけど、てことは何度かgit stageしたそれぞれの
バージョンをみたり、バージョン間で差分見ることができるってこと?
もしそうなら、どういうコマンドでできるの?

git のドキュメントを読んでいる最中なのですが、
subversion と違って履歴を持つオブジェクトの概念があるわけではないので
subversion のような改名いかんに関わらず履歴やdiffを追えるという特徴は
git にはないと理解しました。あってますか。

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
を編集しても文字化けは解消されませんでした。
どのファイルを編集すればよいのでしょうか？

>>449
git log -p --follow <path>

>>450
git commit --amend
でHEADのコミットメッセージ入力をやりなおせる

または、
git reset HEAD^
で一旦HEAD^まで戻してやりなおす。

ちなみに
git commit -F <file>
でファイルからコミットログを読ませることが可能なので試してみて
試してないが -amend との同時利用も可能なんじゃないかな

>>451
どうも。コミットを追跡することでやっているみたいですね。
でもmv後修正してからコミットしたり、あるいはcpでフォークしたり(ファイル
を分割するときとか)はやはり追跡できないみたいですね。

>>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 なのね。

ん 、知りませんでした。ビックリ。

これで、コード変換に纏わる面倒な部分を、(出力時にまわして)
うまく避けてることになるのかな。

tortoisegitの話題はここでいいんだろうか。
indexの存在を完璧に隠蔽しているのはかなり大胆な設計だと思う。

>>452
ar

>>452
ありがとうございます。出来ました。
--amend は直前のコミットしか編集できなかったのですが、
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#rewriting-one-commit
を見て、git rebase と組み合わせると以前のコミットでも修整できることが分りました。

>>456 はミスです...

修正、ではない
残念ながら

>>458
古いコミットを削除？して新たにコミットしている、という事でしょうか？

ハッシュ見れ

>>460
なるほど。
git show "古いハッシュ"
で、古いコミットのログが見れました。
削除はしてないんですね。

>>461
gcしたら消えるよ。どこからも参照されてなければ。

あるリポジトリとそのミラーがいくつかあって、最初にcloneしてきた
ところから普段はfetchしている
$ git fetch
んですが時々別の場所からfetchしたい場合があります。
$ git fetch another_mirror
こういう場合、各ミラーをそれぞれremoteとして登録すべきなんで
しょうか。調べた限りではurl.<url>.insteadof=<alias>を
使ってURLに別名をつけられるのですが、fetchコマンドの最初の
引数にこのURL別名だけを与えても実際にはデータが落ちず、refspec
まで書かないといけなくて面倒です。

間違えた commit は git commit --amend で戻せますが、
git push したのを取り消すにはどうしたらいいでしょうか？

>>464
「取り消す」というのがamendしたものを反映したいという意味なら
git push -f
で上書きできるよ。

>>465
ありがとうございます。
history からも消すことはできますか。

>>466
> history からも消すことはできますか。
んん? 何を消したいのかもう少し詳しく。

>>467
github に git commit & git push してから間違いに気づいてしまったのです。
それを消したいのです。git log から消えたり、
github は history を見ることが出来ますが、それからも消えるとありがたいです。

>>468
何もかも上書きさるよ。
ただgithubってことは既に公開されてるから、他の人があれ何だこれこわい、
ってなるかも。つまりあんまやるべきじゃない。

>>469
ありがとうございます。
確かに消すのはよくないですよね。
( 別の場所から commit したから名前を間違えてしまってｗ )

リモート側にpushされてきた変更を反映するのってどうやるんですか？
git log では表示されるんですけど、master に反映されていません・・・。

>>471
「反映」を適当に解釈してエスパーしてみると、
git pull

>>472
リモート自身に push されてきたものを、自身の master に反映させる、でした＾＾；
リモート(origin)側で git pull する場合ってどう指定するんでしょう？

>>473
「自身の master に反映させる」なら git pull だよ。
リモート(origin)側をどうにかしたいの？

>>474
はい。その通りです。
サーバに置いたoriginに対してローカルからpushした結果を、originのmasterに反映させたいんです。

>>475
ローカルのmasterをoriginのmasterに突っ込むにはこう
git push origin master:master

文章から推測するにいまひとつ理解できてないようなので、この辺を読むことをオススメします
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/gittutorial.html

リモートがbareじゃないのでは?
git checkout -f HEAD

『リモートに push したのに反映されていない』とエスパーしたが
それなら git remote update だよ

皆さんレスありがとうございます。

仰る通りリモートは bare　じゃないです。

git checkout -f HEAD

でリモートの状態を最新にできました！
ありがとうございました！

?

gitメンテナであるHamano氏自身による「入門Git」発売記念age
http://www.shuwasystem.co.jp/products/7980html/2380.html
# 翻訳本の「入門git」じゃないぞ

Amazon はすでに売り切れ状態みたいだけどね。

gitは使われ始めたばかりだから、一番最初にgitの解説書書いたら、売れそうだな

>>482
？？？

>>481
ぎゃー
つい最近翻訳本のほう買っちまったぜ…

Hamanoさんが書くべきだろとは思ってたけど、書いてたのか〜
目次だけ見たけどすごいしっかりしてそうだ。読むのが楽しみ！

まあ、翻訳本もPragProgブランドだし、損にはならないんじゃね?

>>484
ここを読んでもっとwktkするがよい
http://gitster.livejournal.com/38015.html

>>486
ありがとう、livejournalか、そこ知らなかったよ。
wktkが止まらないので、明日本屋うろついてくる。Amazon売り切れ過ぎ、入荷予定遅すぎ。

きっと、Linusの「はじめに」の最後の一文を読んで、
にんまりしてしまうに 1000カーネル

誰か...

>>463
remote 登録すると明示的に指定しなくても、そのリポジトリの全ブ
ランチを fetch してくれるのは.git/config 内でそのリモートリポ
ジトリの設定の fetch の行におまじないが書いてあるから。

別名定義したいほどの頻度で使うなら素直に remote add しろや

>>490
＞別名定義したいほどの頻度で使うなら素直に remote add しろや
>>463にはすまんが、俺もそう思ってた。
てか、refspecまで書かなきゃダメ、とかいろいろ試してみたんだったら、
MLで質問したほうが良いんじゃないかな。bugかもしれないし。

>>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
指定を楽にしたい理由があんま思いつかない。

最近GitHubが重いと思う
GitHubの収益源ってなんだっけ？

有償アカウントとか講習会とか業務への導入サポートとか。
鯖はEngineYardだな。

それだけで賄えるものなのか

時々サーバ死んでるよね
タダで使い倒しておいてあまり文句いう筋合いもないけれど

無料でしか使う予定はないけど頑張ってほしい

http://fi.github.com/
そういえば、こんなのあったね。

Gitはじめてなのですが、バイナリの履歴はすべて持っているのでしょうか？
それとも差分だけ？また、ローカルリポジトリには圧縮されたバイナリはどのように
保存されるのでしょうか？バイナリサイズが大きいプロジェクトで使用予定なのですが
ローカルリポジトリが膨れ上がるのを恐れています。

.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

thunks! 時間がくれば pack されるのですね。
まあ、HDDスペース節約よりは速度重視な最適化というわけですね。
HDDは、いっぱい増やすしかないかぁ。
後 Windows のファイル名の日本語処理がまずいところが不満ですね。
これさえ解決すれば svn から乗り換えるんだけどなぁ。来年ぐらいかなぁ。

>>494
あれなんかEngine Yardじゃなくなってるぽい。
こないだのメンテで移動したのかな。

なんか新しい本買った人いる？

"pro git" pdf
でぐぐれば面白いのが見つかるぞ

git clone git://git.example.org/cgit.cgi/xyzzz/tree/?h=newton

git で下の階層に置かれている newton を
持ってくるにはどうしたら良いのでしょうか？

xyzzz を持ってくるのはできるのですが…　　　

自己解決 >>329-334 辺り感謝

git clone -n git://git.example.org/xyzzz
cd xyzzz
ls
git checkout -b newton
git fetch

で取りあえず上手く取ってこれるみたいでした
なんでも一行でやろうとするなじぶん('A

>>506
git cloneで既にfetchしているんでcheckoutの後にfetchしなくても

>>501
>後 Windows のファイル名の日本語処理がまずいところが不満ですね。
$ git config core.quotepath true
でもだめでしょうか。

> git config core.quotepath true

cygwin 版の話ですかね。基本エンジニア以外も触るのでTortoiseGit の(MSYS版)でコミット
した後の亀が飛んで行ったところのメッセージが必ず文字化けしているのがちょっと嫌ですね。
また現在 svn を利用していてこちらを git-svn で使用したいのですがこれも MSYS版には
入っていないようなのでそこもネックになっています。

>>509
msysgit(PortableGit-1.6.3.2-preview20090607) + TortoiseGit 1.0.0.2にて
git-svn をGUI経由で使えてますよ

git-svnにはハマリどころがありました。
svnリポジトリとシンクロしているgit側ブランチでgitのマージコミットをつくったりすると
git svn dcommit時にエラーになるので要注意ですね
ここらへんに情報があります
http://learn.github.com/p/git-svn.html
Rules and Guidelines

TortoiseGit に同梱されている

途中での書き込み、すまん。

TortoiseGit に同梱されている igit.exe のソース
どこにあるか、知っている人いたら教えてもらえないだろうか？

どうも TortoiseGit のリポジトリの中にはなさそうなんだけれども。

Linux板でWindowsのソフトの話すんなよ

Windows版のgitはまだまだだよって、開発者自らいってて、どんどんフィードバックしてくれって言ってるんだから
Windowsでgit使いたいんなら、フィードバックしないと一向に改善されないと思うよ
git開発者は、Windows特有の問題とか疎いだろうし

重ね重ねすまん。
スレタイのみで検索して書き込んでしまった。

分散型バージョン管理システムのフロントエンドを

git の Windows 版フロントエンド作りたいなぁと思って
TortoiseGit のソース見てたんだが、

また、途中で書き込んでしまった。
ごめん、反省した。途中だけど、もうやめる。

>>513
次スレはム板にする？

ここ、隔離スレかと思ってたんだが

Windows上でgit使ってる奴なんかいなんだから、Windows特有の問題なんかしらないってことでしょ

>>512　恥ずかしいやつ過ぎるwwwwwwwwww

>>515,517
プログラム板にバージョン管理システムのスレあるけど、、、
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
板違いにはならないだろうけど、、、コアな話題はここでも良いんじゃないかなぁ

>>519
あっちのスレ見てると、使ってる人居るみたいだよ。
日本語ファイル名で苦労するようだけど、UTF-8 Cygwinではちゃんと使えてるらしい。

そりゃ、あっちのスレではいるだろうよ(あっちがどこなのか知らんけど)
ここはLinux板

＞Windows上でgit使ってる奴なんかいなんだから
ってお前が言うから、教えてやったんだぜ。

この板だろうが、あほ?

安価もつけてない２ちゃんのレスを自分だけのメッセージって思うようになったら
終わりだぜ。しばらくmixijかtwitterでもやってたほうがいい。

は？　LinuxもWindowsも両方使ってる奴だって居るだろうが、カス？

で、ここは本スレなのか？

一応。

まあ今はム板にある Subversion スレも、この Linux 板の卒業生だしな。

[ANNOUNCE] GIT 1.6.5
ttp://article.gmane.org/gmane.comp.version-control.git/129906

Git-1.6.1-preview20081227.exe から Git-1.6.4-preview20090730.exe に
乗り換えたら確かに git-svn を TortoiseGit から使えました。Windows も実用段階
に入ってきましたね。

>>531
>Windows も実用段階に入ってきましたね。
きっとﾋﾞﾙｹﾞｲﾂも喜ぶよ、それ言ってやったら。

   【恐怖の】呆れるほど危険な民主党の正体【民主党】
    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
    日米規制改革および競争政策イニシアティブに基づく日本国政府への米国政府要望書
    http://japan.u●sembassy.●gov/j/p/tpj-j2●0041020●-50.html#mineika-s

●の部分は外してブラウザのURLに入れること

もしかして git って名前通り、日付指定で checkout できないの？



やっぱ馬鹿。

>534
なぜできないと思ったのか詳しく。

>>534
おみゃーがgitなんでは

But while these inter- ventions slowed the adjustments of the market, these adjustments were still in ultimate control of the situation. ,

This initial post on Every Kitchen Table frames the need for new food systems connecting more consumers with sustainably grown, processed and transported food. ,

最後にコミットした時のログメッセージの再編集は git commit --amend でできるのですが、
何世代も過去のコミットのログメッセージの再編集はどうやればできるのでしょうか。
それともそんなことはできないんでしょうか。

git rebase -i HEAD\~5
みたくやって pick を edit にして、--amend の時に変更かな

>>539
色々やり方あると思うが、例えば git rebase -i ... で編集したい commit を "edit" に設定
して、そこで git commit --amend とか

ttp://progit.org/book/ja/ch6-4.html

git gui は日本語UIにできるのに、 gitk はできないのも妙に思い、日本語訳を試みてみました。
妙な日本語訳の改善案などがあればお知らせください。

http://lab.mzr.jp/gitk/

>>539
脳内で考えるような「単純な差し替え」は厳密にはできない
「以前と同じ修正群と、以前と違うコミットメッセージ」を持ったコミットの列を作って繋げなおす、という手順になる
動作的には同じだが、オブジェクトとしては別だし、ハッシュ値も違う
push した後だと以前のコミットと同一視させる手段がなくてたいそう悲惨

もちろんそれは正しいけど、commit --amendを持ち出してる
のを見ると、そこらへんは分かってるように見える。

Gitの実装はいつCからGoに切り替わりますか？
ttp://pc12.2ch.net/test/read.cgi/tech/1257079004/90-

>>546
どっちだ?
http://golang.org/
http://books.google.com/books?id=jyIrfDokmKgC&dq=isbn:0975444913

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しても同じメッセージが出ます。
どうすればいいんでしょうか？

git fetchして、git rebase masterすると同じメッセージが出たのですが、
git rebase -i masterすると問題なくリベースできました。
解決はできたのですが、なぜgit rebase masterでリベースできないのに
インタラクティブモードではできるのか、わけがわからない・・・

>>548
rebaseの内部でコケてるみたいだけど、遭遇したことないなあ。
バージョンは？　もしかしてCygwinだったり？

>>548
rebase -i masterでリベースできるってことは
ふだん使うブランチはmasterではなくて、
masterっていうローカルブランチがたとえば
ref: origin/master
みたいになってたりするの?

すみません、煮詰まってしまったので詳しいかた教えていただけないでしょうか

bareじゃない二つのリポジトリAとBがあります。
（BはAからのクローンです）

Bで変更を行ってAにPushしたあと、Aでgit statusすると
A上ではBで行った変更の真逆の修正が行われてステージされていることになっています。

これはどうしてでしょうか？

純粋に期待している動作（A上でもBで行った修正がコミット済みになっていて何もステージされていない状態）にするにはどうしたらよいのでしょう？

>552
ステージされてるなら git reset なり git checkout . なりすればいいんじゃないの？

>>552
bareじゃないとこにpushじゃしょうがないんじゃないかな。
Aでpullしたらいいんじゃない？

回答いただきありがとうございます。

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

間違えました。

誤：現状ですと、正しくPushするためにはbareじゃないリポジトリを
正：現状ですと、正しくPushするためにはbareなリポジトリを

たびたびすみません。自己解決しました。

BからAにPushしたあと、Aでgit reset --hard
すればいいだけでした。

返信をくださった方ありがとうございました。

バイナリファイルがコンフリクトした際にどのように対処してますでしょうか
マージすることが不可能な場合、どちらかのファイルを選択することになりますが
自分の作業を優先してコンフリクト解消する場合には

git add コンフリクトしてるファイル
git commit

これでコンフリクト解消できますが、相手のファイルを優先したい場合に

git reset コンフリクトしてるファイル
git commit

をすると両者の作業がなかったことになってしまいます。

相手の作業を優先する場合にはどのようなコマンドを打てばよいのでしょうか

git checkout --ours --theirs

ttp://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.6.5.4.txt

　-----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な状況なんだかよくわからないです。どうやったら直せるんでしょうか?

>>561
pushとpullって名前からしてやることが近い気がしてしまうけど、
pull：remoteをfetchして現在のブランチにmerge（fetchしてmergeするのと同じことが起こる）
push：remoteブランチをローカルのブランチで上書き
なので、pullはfast-forwardじゃなくてもマージコミット作ってくれるけど、
pushはマージはしないのでfast-forwardじゃない時は怒られる。forceオプションで強制pushすると
ヘタするとremoteブランチのコミットが失われる。

fast-forwardの意味が分からない場合は、チュートリアル見ると良いと思うよ。
Git入門 - トップページ
http://www8.atwiki.jp/git_jp/

>>562
「なんでnon-fast-forwardな状況」であるかの説明になっていないけど

>>563
それが分からなければチュートリアル読んだほうが良いと思ったから。

>>564
質問は「なんでnon-fast-forwardな状況」なのかであって
「(non-)fast-forwardとは何か」ではないので、だったら
>>561の説明自体無駄で最初からチュートリアルのURLだけ
案内するのと変わんねーじゃん

>>565
ほんとだ、俺寝ボケてたみたいだわ。ごめん。

>>561
Bの進化分は既にAに反映されているが、Cはそれ以前のAの状態を元に進化しているので、
non-fast-forwardということになる。

Git 1.6.5.5
ttp://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.6.5.5.txt
＞Manual pages can be formatted with older xmlto again.

若干荒れ気味になってすみません。
>566
>Bの進化分は既にAに反映されているが、Cはそれ以前のAの状態を元に進化しているので、
でその通りでした。Cで
$ git pull B
コンフリクト等解決して
$ git push A
でOKでした。

で、思ったんですが、non-fast-forwardな原因を追いかけるのはどうやるのが一番わかりやすいですかね?
私の今回の場合、過去にどう作業していたか思い出した、という原始的な方法だったんだけど、便利なコマンドとかありますか?
$ git log --graph
とか見ても、ごっちゃで気づけなかったです。

>>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とか。

>>569
gitk --all と打つとグラフィカルにグラフ表示してくれるので
fast-forwardかどうかすぐわかる

>570,571
リモートのコンソールにログインして使うことが多いので、gitkは使えないんです。
X飛ばすのも面倒な環境だし。
git show-branch の見かたを覚えることにしますわ。

git clone すればいいんじゃね？

入門Git買ったんだが、これ分かりやすいな
さすがに濱野さんが書いてるだけあるか。

チームで使うSCMをSubversionからGitに変えたいんだが
メンバー全員に正しいGitの使い方を教育するのは、骨が折れそうだな・・・

>>574
入門Git、神本なのは確かだけど、俺としては日本語ちょっとクドい気がしたな。
アメリカ在住らしいから、脳が英語になってるんじゃなかろうか。

Gitって、viとかみたいに取っ付きにくいけど慣れてしまうと手放せなくなる
典型的な麻薬ツールだと思う。そのぶん障壁が高くて文句言われがちなんだけど。
だから「メンバー全員に正しいGitの使い方を教育」するのは、難しいだろうけど
そのぶん感謝もされるし、また始めての人にどう教えたら本質を理解してくれるのか
というのは、とても有用な情報だと思う。

>>574
良い本だとは思うけど、わかりやすくはないと思う。
まわりを教育するには初心者向けのわかりやすい本が欲しい。

>>575,576
日本語で読めるGitの入門書って濱野本、でびあんぐる本、ProGitくらいしかないしなぁ

でびあんぐるのは知らないけどProGit、濱野本の順で読ませるのが分かりやすいんじゃないかな

>>575
Gitが難しいのは、思想や観念を理解するのが難しいわけじゃなくて
コマンド/オプションが多すぎる、同じコマンドで2種類以上の役割を持たせてる
あたりが敷居を高くしてる気がする

>>578
いや、コマンドの数が多いのは確かだけど、普段使うものは数えるほどしか無いよ。
それに全コマンド一覧なんて初心者に見せるか？　下位レベルコマンドは知る必要ないし。

もっとも障壁が高いのはGitの本質を知る事だと思う。特にsvnをやってた人は
「Gitで何が出来るのか」ではなく「svnでやっていたことをGitでやろう」とするので
自分がやっていることがほんとうは何を意味するのかよく分からないまま使うことになり、
「使いづれー」ってなる気がする。
頭を切り替えてチュートリアルを実践するだけで、けっこう分かると思うんだけどな。

>>577
最近初心者向けにGitのことブログで書いてる人も多いね。俺は純正チュートリアルでも
けっこういけると思うんだけどね。最初は会社の同僚からGit教えてもらったんだけど、
これは麻薬ツールの典型なんだが、会得してしまった人は会得してない人に教えるのが
上手くできないんだよね。viとかemacsとか、そう簡単に教えられるものじゃないみたいに。
だから結局は全て自分でチュートリアルやって覚えたけど、最初はどうしてもsvnとかに
なぞらえてしまって、イライラしたな。

>>578
resetはreset(巻き戻し)とunstage(indexからの削除)に分けるべきだよな
他には何があるっけ？

>>579
Webなんかでも、svnのこのコマンドに相当するgitのコマンドは何？って質問が
結構あるしやっぱり本質は理解されてないかんじですね
indexも存在意義がわかれば非常に便利なんだけど。
Winの話題で申し訳ないけれど、TortoiseGitなんかもindexの存在を隠して
ワークツリーから直接コミットするような作りになってるし

＞これは麻薬ツールの典型なんだが、会得してしまった人は会得してない人に教えるのが
たしかにそうですねｗ

>>580
よく使うコマンドだと
checkout ブランチ名（ブランチ切り替え）
checkout -- ファイル名（ファイル取り出し）
reset HEAD^（コミット取り消し）
reset ファイル名（ファイルアンステージ）
reset --hard（ワークツリーの修正取り消し）

言葉で伝えるのは難しくて
チュートリアルをいじって自分の頭の中に動作イメージを作るか
よくできた紙芝居を見せてもらうかしないと
「わかった」とはならなよね。

>>580-581
まあでも「alias書けば?」で終わるレベルじゃん

だよね

打つのがめんどいって話じゃなくて分かりづらいって話では？

aliasには「分かりやすい名前をつける」という機能もあるんだけど

一度やりたいことをしてくれるコマンドを知れば別名も
付けられるんだけどねー。
分かるまでがたいへん。

そのaliasを設定するためにはコマンドの使い方知ってなければ
ならないが、話の論点わかってますか？

aliasでこんなんやっちゃう人もいるみたい
ttp://github.com/blog/564-hub-git-with-github

俺はrefspecの表し方がよく分からない。
文脈で書き方が
$ git push repository branch
だったり
$ git merge repository/branch
だったりするところとか。理解しきれてないからなんだろうけど。

>>588
そしてある程度分かってきたら、よほど長くない限りalias使わなく
てもよくなるんだけど、誰かが作ってくれたalias集をwebから
持ってきて、... なんて方法も今はあるからね。

リモートブランチの扱いが俺も最初はとまどったけど
省略形じゃなくてフルで記述するコマンド体系を覚えてから
省略形を使うようにしたら、すんなり理解できた

$ git push repository branch
は
実は
$ git push repository branch:branch
の省略形で、手元のbranchからrepositoryのbranchへ対してpushしなさいという意味

一方mergeのorigin/masterなどは、具体的なコミットを指しているので
リポジトリ名/ブランチ名となる

>>592
もう忘れてたけど確かに俺もそうだわ。
pushはフル書式で理解するまではかなり自信なさげに使ってた。

1.6.6 released

stashとresetに頼りまくってる自分の使い方は邪道なんじゃないかと
気になるんだが、indexとかうまく使えば減るだろうか

>>595
運用上不都合がなければいいんじゃない?

>>595
reset、rebase、resetに頼りまくれるようになってはじめて、一人前のGit使いだと思う。
commitとmergeだけじゃ今までのVCSと変わらないじゃないか。

reset、rebase、resetってなんだよorz
reset、rebase、stashのつもりだった。。。
あとrebase --onto、rerereなんか使うとさらに先にいける。

おーでかーけでーすかー

今だにpush,pull,rebaseの使い分けがわかんないんだよな。
普段git svnでやりとりしてるとrebaseだけで事足りるというだけなのか

そりゃgit svnではpush, pullは使いようがないというか、使ったらぶっ壊れるんじゃ。

他にもgit svnを使っているメンバーがいた場合、
そいつとは、pushやpullができるという

>>602
でも結局いつかgit svn rebaseするから、ID全部変わるしマージコミット入れられないしで
うぼわーマジsvnやめようぜクソがぁ！
ってなる。

しかしsvnに入れた分はちゃんとIDそろうのはすげーと思ったな。

オリジナルの拡張子を持ったファイルをコミットすると、rawファイルとして認識されるみたいですが、
textファイルだとgitに教える方法はありませんでしょうか？

>605
gitattributes で crlf と diff をセットだと思う。

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が空になってしまいます。

git describe --always

git rev-parse HEAD

github は、タグからアーカイブを生成する場合、アーカイブのファイル名にタグ名を含めてほしい。

example.log っていうファイルがあって
このファイル自体はpushされていて、でも今後の変更分についてはpushしたくないってとき、どーするのが正解？

git rm --cached して版管理自体をやめるわけにはいかないんだけど

ignore すれば？

>>612
すでに版管理されてるからmodified filesとしてあがってきちゃう
commit対象としてのみ無視したいんだけど、ignoreできるの？

>>611
ローカルリポジトリでバージョン管理するのを止めれないなら
ignoreできないから、簡単な方法はないでしょう。
push用のブランチを作り、手でrebaseしてそのファイルへの修正が
入らないようにしてからpushするとかしか思いつかないけど。

push 用の branch とローカルでの example.log の変更を commit する branch とを作ればいいんじゃないかな。

CVSやSVNは集中型、gitは分散型 とあるんだけど
何が集中したり分散したりしてるの？

リポジトリ(履歴データを持っている場所)が1つか、複数か。

集中型は権力も集中しがちになる（コミット権がうんたら）

じゃあgitはオープンソースに適してるんですね。
仕事用で使いたくて、なるべく権力を集中させたいので
gitは見送ります。ありがとうございました。

ワークフローは運用次第ってだけの話だが。
http://progit.org/book/ch5-1.html
http://github.com/progit/progit/blob/master/ja/05-distributed-git/01-chapter5.markdown

分散型に出来て集中型に出来ないことは無いんじゃない？

あれ逆か、集中型で可能なことは分散型で出来る。

>>619
要は、運用次第で権力集中可能
例えば、マスターリポジトリの更新権限を限定するとか（つ〜か普通そうするんじゃ…)

>>622
オフラインでのコミットとか無理じゃね？
ローカルにリポジトリあれば別だけど自分以外ができないからあれだし

あと、うっかり変なcommitをしてしまったとき、gitならpushしない限り大丈夫だが、
集中型だとお説教タイムになってしまう悪寒

>>625
巻き戻せばいいだけでは。

>>626
普通巻き戻しは特権がいるんじゃない。　で、特権のある人に
お説教されるとw

お説教なの? ニヤニヤされるんじゃなく?

せんせーきほんてきなしつもーん

ターミナルが A と B の 2個あったとして、
A で git checkout one したあと
B の Emacs でたくさん git 対象ファイルを開いて、そのまま、
A で git checkout two するとします

Emacs で開いてるバッファ内容ってやっぱり one のままだよね？
バッファを編集して保存したら one のファイル内容が two のファイルに上書きされて「危険」だよね？
A でブランチを切り替えるたびに Emacs のバッファは全部閉じて再度開きなおさないといけないよね理屈上

emacs使いじゃないから知らないが、バッファ読み込み後にファイルが更新されてるのを
警告もなしにそのまま上書きしちゃうのか？

ﾆﾔﾆﾔ

ちゃんと警告してくれますよ。

screen と emacsclient使え。

Emacsの revert-buffer を使えばバッファを再読み込みしてくれるけど……

>>629
危険ていうか、それはgitじゃなくても他の端末から同じファイルを編集したら同じことになるでしょ。

俺はvimだけど、ブランチ切り替えもそうだけど、git stash -> git svn dcommit -> git stash pop
ってやった後に保存しようして、警告が出るな。
このパターンだと十中八九ファイルの内容は変わってないんだけど、念のため確認するようにしてる。

git-mode上でブランチ切り替えたら再読み込みしてくれたりしないかな

ようはEmacsがブランチ変更を検知しないことが問題なんだよね
上書き警告だって本質的な対策じゃない
ブランチが変更されたんだから、編集したいのはそのブランチのファイルのはず

Emacsの普通の設定ならタイムスタンプが変わってたらrevertするか聞いてくるだろ

>>637
それがめんどくへえという話なのでは…
編集中のバッファでなければこっそり開きなおしてくれてるくらいのサービス精神がないと
不況下の日本ではEmacsは生き残れないぞたぶん

>>638
そうしたいならそうすればいいじゃん

git はメンテしてる Junio Hamano 氏がとんでもないナンパ野郎だと知って以来、
極力避けるようにしてる。濱野氏がメンテから降りたらもっと使ってもいいかな。

ふーん

>>640
どのへんがナンパ野郎なのか教えて

濱野氏は、美人研究者のブログで、その人が git 好きなのをネタにして、
「今度 git の講演に日本に行くから、その時に二人でデートしようぜ」
と本気でナンパしていたと聞いている。

べつにgitをユーザが増えようと減ろうとJunioのナンパに貢献する
ことはないと思うけど、それ以前に共通の趣味をネタに口説くこと
がどうまずいのかも不明。

女を捨てまくってるとかならともかく、アプローチしてるだけでそこまで嫌悪する必要ないだろ

>>643
糞ワロタwww
ブログでかよ？
他に読んでる奴等もいるだろうし、
さすがにそれはねーわなw

gitに使う価値があるかどうかは、
メンテナ氏の女性へのアプローチ法とは関係がない

どこのblogかkwsk

嫌儲の男女バージョンみたいな感じだな

>>638
auro-revert-bufferじゃだめなのか？

ソースコードを本番にデプロイする時についてなのですが、
前回デプロイ時のソースとの差分だけ抽出して、そのファイルだけ本番にデプロイできるようにしたいと考えています。
今レポジトリにコミットしたリビジョンと、前回デプロイ前のコミット時のリビジョンの差分を
抽出することができればと思うのですが、それ用のコマンドってgitにあるでしょうか？？

教えていただけると幸いです。

すいません、言葉足らずでした。
>>今レポジトリにコミットしたリビジョンと、
>>前回デプロイ前のコミット時のリビジョンの差分を
>>抽出することができればと思うのですが、

更新のあったファイルの「ファイル名」だけ、gitのコマンドで抽出できないか、という意味です。

>651
どーやってデプロイしてるのか教えれ。

>>652
git diff --name-onlyとか、どう？

>>651
普通にgit pullしたら早いと思うんだけどな。
rsyncするよりも手軽だし。

レスありがとうございますm(_ _)m

>>653
ftpかsftpでデプロイしようと思っています。
本番環境はさくらインターネットの供用サーバです。

>>654
やってみました。
これって、コミットする前の、さらにステージする前の差分ファイルを抽出するんですね。
git diff --cached --name-only って試してみたらステージ後の差分ファイル一覧も出力出来ました。
やろうとしていることは大体こんな感じなのですが、
２つ前のコミットと１つ前のコミットの間で更新されたファイル一覧の出力ってのはできないでしょうか？？

>>655
なるほど、本番環境に入ってpullするんですね。
仕事では本番サーバも自分で用意してgit環境も構築してたのですが、これってやったことありませんでした。(普通にsftpとかrsyncで・・)
ただ今回の場合、デプロイ先がさくらインターネットの共有サーバなので、git環境を構築出来ないと思うんですよね。
なので普通にftpとかsftpでアップしようと思っています。

ちなみに、本番環境でgit pull する方法で、本番ウェブサーバが複数ある場合は、
それぞれにログインしてウェブサーバ毎にgit pullする感じですか？

>>656
＞ちなみに、本番環境でgit pull する方法で、本番ウェブサーバが複数ある場合は、
＞それぞれにログインしてウェブサーバ毎にgit pullする感じですか？
どれぐらい気をつかってやるかにもよるんじゃないか。
静的コンテンツをただ更新するだけならrsyncとかgit pull/pushとかをスケジューリングで
自動でやらせてもいいかもしれないけど、warなんかだとそうもいかないだろうから
リリース毎にウェブサーバ切り替えながら慎重にやるんじゃない？

てきとうにググったら、さくらのレン鯖にGit入れてる人けっこう居るみたいだよ
ttp://www.google.co.jp/search?q=%E3%81%95%E3%81%8F%E3%82%89+%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC+git
俺もさくらのやつあるんだよね。今度やってみようかな。

>>657
レスどもです。

そーか、スタンダードプランならsshとか使えるし、gitのインストールもできるんですね。
早速
http://d.hatena.ne.jp/higepon/20091119/1258633627
これみてやってみたんですが、
git push --all
のところで
Permission denied (publickey,password).
fatal: The remote end hung up unexpectedly
っていわれてしまいました。

さくらのスタンーダードプランのssh接続って試してみたら
鍵認証なしの単純なパスワード認証みたいなんですけど、
git push の時のssh接続では鍵が探されてる？気がします。
上の記事書いた人はなんでうまくいったのか・・
git://プロトコルにするとポートが開いてないみたいでダメです。思案中・・

>>658
単に向こうの~/.sshやauthorized_keysのパーミションの
問題とかではなく?

>>659
いま一応確認してみましたが、~/.ssh のパーミッションは755で、authorized_keysはありませんでした。
普通にsshでログインしようとしたら鍵認証じゃなくてパスワード認証になるので
authorized_keysはないのは問題ないと思うんですが
gitでssh接続しようとするとなぜか鍵認証にしようとします・・なぜだー。

man co

>>656
> ２つ前のコミットと１つ前のコミットの間で更新されたファイル一覧の出力ってのはできないでしょうか？？

git diff --name-only HEAD^^ HEAD^

それぞれのcommitのSHA-1値を与えてもOK。詳細は git diff --help してみるのがよいかと。

1.7.0 ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ttp://article.gmane.org/gmane.linux.kernel/949579

あれなんか空のディレクトリいつのまにかサポートされてる？

>>664
mjd??

>>647
reiserfsを使っている俺には死角はなかった。

http://progit.org/book/ja/

お、ちゃんと日本語に戻ったな。
ちょっと前まで何語かよくわからんのにすり変わっていて笑ったんだけど。

>>663
repo.or.czのミラーって更新遅いんだな...

ようやく、なんとか git add -p / git commit -v
に慣れてきた感じ。

git add も当たり前だがわかっててやらないと(?_?)な
状態にすぐなる。git add -u とか
git commit -v -m "hoge" huga.txt
とか、けつまずいた。git reset HEAD^ に何度も助けられたぜ。

俺も最近なれてきたけど
少し前まではgit pushした後、
別の日にgit commit --amendから初めて
git pushして、パニクってたものです・・・

サブモジュールとサブツリーってどう違うのかよくわからん。
複数プロジェクトを1レポジトリでまとめたいんだけど
どうすりゃいいの？

復活カキコ

みなさん、もう$Id$とか使ってないですか？

それgitで使えるの？
blameとか見ればいいんだし使わないよ

最近TortoiseGitが1.3.6にヴァージョンアップしたもようですが
1.3.2対応の日本語化パッチが使えなくて困ってます。。
是非1.3.2にヴァージョンダウンさせたいんですが本家のぞいても前ヴァージョンが無いんですよね・・・
どこかに1.3.2転がってませんかね？

>>675
開発元サイトにあるぢゃん
ttp://code.google.com/p/tortoisegit/downloads/list?can=1&q=&colspec=Filename+Summary+Uploaded+Size+DownloadCount

msysgitの方も最新版出ないかなぁ

>>674
attributesファイルに * ident って書けばできるんですけど、
日付とかではなく、コミット名(ハッシュ値)になるみたいだし、
checkoutした時しか置換されないようです。
今までSubversionとかで$Id$使ってたソースをGitに移した場合、
全ファイルのこの部分は、この先どうしていけばいいんだろう？と思いました。

正直RCSキーワードのためにしょうもない(前処理で$Id$に戻すとか)
コミットスクリプトが必要なのが無駄。気にしないようにするか、
日付やリビジョンを含まない形に全置換しとくかすればいいと思う。

CVSだとそうなんだけど、svnだとスクリプトは不要なのかな?

TortoiseGIT より期待してる git extensions が backend として cygwin 1.7 も
使えるようになり、UTF-8化が可能になるかと期待したが、cygwin の git process
呼び出しで、.netが勝手にlocal cp(日本版ならcp932)に変換しやがる。
stdoutとstderrは、encodeを変えるオプションがあるし、実際それを使って、utf8
文字列として読み込んでくれるんだが、何故かstdinには無い。
processの引数と、stdinをutf8で渡せれば何とかなりそうなんだが・・・

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フォルダにアクセス出来ないようなんですが・・・

http://qb5.2ch.net/test/read.cgi/saku2ch/1268173920/

さてさて
やれやれ

>>682
「スクリプトファイルが反応して」ってどういうこと?

お騒がせしてすいません。
特に何も入って無いサーバーなので、特に問題は無いと思うんですが、
念のためapache等は落としておきます。
徹夜明けの寝ぼけた頭で投稿したのがまずかったようです。

>>685
普通にapacheで動作するスクリプトファイルを置いていたので、
git clone 'http://〜'だと反応したんだと思います。
"ForceType text/plain"かchmodで対応してみようと思います。

すいませんでした。

セキュリティが不安なら、そもそも公開すんなよ

優しくしてやれよ！

削除要請板からきますた
なんか色々大変ですね

名前まで出してしまいましたね。

わざわざ削除依頼なんてしなけりゃスルーされたよね

どうかな

俺は気づかなかった。見た瞬間とりあえずくだ質問行けよとか思った。

>>686
>git clone 'http://〜'だと反応したんだと思います。
だから反応ってどういうことだよ池沼が

まあ落ち着け。
とりあえず俺はgitどころか
カーネルのアップグレードに失敗したらしく
かなり焦ってる
バックアップの必要性は必要になってから気づくんだ

コミットの指定で使う ~ と ^ の違いがよく分からないんだけど、
例えば、HEAD~2 とか HEAD^2ってどう使い分けたらいいの？

縦軸と横軸だ

c~3-c~2-c1~-c(HEAD)
　　　　　　c^2 」
　　　　　　c^3 」

c~3-c~2-c1^-c(HEAD)
　　　　　　c^2 」
　　　　　　c^3 」

^複数の親と、~複数の世代の違い

その２つは異なるものだよ
~nはn個前の親を表していて
^nは1つ上のレベルのn個目の親を表す
　　D-E
　 /　　　\
A-B-C-F
FがHEADの時にAはHEAD~3
CかEがHEAD^1、HEAD^2。

ありがとうございます。やっと分かりました。
^はマージによってコミットに複数の親がある時、それぞれの親を指定できるんですね。
すっきりしました！

すっきりしない

subversion からcloneしたリポジトリで git branch -r　すると@12とか
複数のバージョン？見たいなのが出てくるんですが、これはなんですか？

gitは基本的に戻ることはないんだねぇ、
恥ずかしい失敗したらコマンド使ってコミット無かったことにするけど

基本的に戻ることがあるようにしてるVCSなんてあるの？

git reset でいくらでも戻れるぜ。ただ、それよりも
1. 作業用ブランチでは気にせず commit/revertしまくる
2. 作業終わったら作業用ブランチの根元から新しくブランチを切る
3. cherry-pick とかで綺麗な履歴を合成
4. 作業用と新ブランチのdiffに差がないことを確認
5. 作業用ブランチはまるごとさようなら
がオススメ。1commit に複数の仕事を含めないようにしないと後で
カオスになるけど。

>>706
お前は俺かｗ
そんな神経質なことやってるのは俺ぐらいなもんだろうと思ってたぜ。
ただ、履歴が綺麗だと気分良いけど、仕事ではそれなりで我慢するようにしようと心がけてる。

あとそのやり方やってると、diffで何も出ないんだからgit branch -D でさよならで
良いはずなんだけど、どうも念のために残しておきたくなっちゃうんだよな。。。
だからtopic_bk1 topic_bk2 ... とかいう感じで、ゴミブランチがたくさん残ってしまう。

それでいいんじゃね？　増井俊之のいう富豪的プログラミングの一例として

テキストデータなんてどうがんばってもHDD1台分も書き溜めることはできないんだから
いくらでも残しておけばいいんだと思うよ

でもあれだぜ、git branchが一画面分超えちゃうようになるとちょっと考えちゃうぜ。
デフォで git branch | grep hogehoge しないと使ってられない。
ってまあ、そうなる前に整理しろって話なんだけどね。。。

手動でgcした時だけ消える（消えなくてもいいけど）普通にはリストに出てこないtrashes的な属性が
ブランチに付けられたらいいなと思った。けどgit-branchはスクリプトじゃなくてC実装だったので寝る。

あー、なるほど、作業用ブランチでrevert使ってなかったわ

1.7はこんなん変わってるから注意、みたいなの教えて欲しい

git tag は-lでタグ指定して見られるのに、git branchは一覧しか見られないのはどうしてなぜなんだぜ

>>712
tagは、大抵付けっぱなしだけど、branchはmerge済みになれば(俺は)消しちゃうから
選ばなくても、そんなに沢山出てこないんじゃないかな？

>>709
ゴミブランチが多すぎてうざくなったら、clone して
別リポジトリでとっておけばいいんじゃね？
また必要になったら pull すりゃいいだろうし。

ちなみに >>706 の 3 は commit が多い場合 cherry-pick じゃなく
て format-patch でファイルに落としてから選別、 git am で一気
に進めると楽。ただし、commit log の1行目に適切なサマリを書い
てないと選別作業がカオスにw

あと応用として「なんか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. 作業用ブランチはまるごとさようなら
とかでサクッと分割できる。

ついでにもういっこ。
この手の作業するのに gitk --all は欠かせない。各ブランチHEAD、
ブランチ間のつながり等が一目瞭然なのでイメージをつかみやすい。

>>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 とかつけてね。

ということらしい。

>>718
なるほど。すません、英語読むの面倒くさがって。
git1.7は一部後方互換性なし、って見出しでよく言われてるけど、普通に使ってるぶんには
まったく問題なさそうだね。チェックアウト中のブランチにpushしたらデフォで拒否ってのは
安全でとても良いと思う。

>>714
なるほど、そうしてみるわ。ゴミ置き場リポジトリね。最近cloneはハードリンクがデフォになったようなので
そこは注意だけれども、、、

>>717
そうそう、gitk以上に見やすいのは知らない。つってもマージ激しくない時はshow-branchでどうにかなるけど。

>>716
それって最終的にマージして終了？　まっすぐにして残そうとはしないの？

GUIならgitkかqgitかな、と思ってる

>>719
> >>716
> それって最終的にマージして終了？　まっすぐにして残そうとはしないの？
おっと、topicA, B ともに、まだ作業中のイメージでした。
作業が完了してるなら統合用ブランチにマージして終了ですな。

http://sourceforge.net/dbimage.php?id=72597

ずうううううううっと思ってたんだけど、コミットログ書くときに今回どこを変更したかってふつう覚えてなくね
コミットログに書いておくべきであるような変更をぽろっと書き損ねるとかありそうでヤじゃね
それとも忘れないような小さなカタマリで鬱陶しいほど細かく作業単位でコミットするもんなの？
それともみんなコミットログ書くときには別窓で git diff とかの結果眺めつつ書いてるの？

>>723
＞コミットログ書くときに今回どこを変更したかってふつう覚えてなくね
git commit -v 使うといいよ。
どこを変更したじゃなくて、なんで変更したのかを書くといいよ。
git diff使えば変更点なんかすぐ分かるんだから。

＞小さなカタマリで鬱陶しいほど細かく作業単位でコミットするもんなの？
鬱陶しいかはしらんけど、俺は結構細かくつけてるけど。
一気に変更した後、git add -p使ってコミット自体は細かくしてる。
この時に、意味的に1種類のコミットにするようにして、
すぐgit commitしちゃうから-vオプションつけなくても、
コミット内容は頭に入ってるかな。

>>723
何か目的があってソースいじってるんだから、その目的を書けばいいんじゃないかね。
逆に言うとどんだけデカい差分になってもいいから、別の目的の差分は入れるべきじゃないと思う。
例えば、機能追加なのにちゃっかりバグフィックスも混ざってるとか。

>>723
gitx ではとりあえずコミットログを書きながら
コミットするファイルの一覧から diff 表示させられるから
忘れてても全然 OK

muzu-

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には対応しているはずなんですが。

数値でっていうかバイナリなのか。gitはファイル名をバイナリで扱うんだっけ・・・

gitで日本語ファイル名を無理やり通した - きみのハートを8ビットキャスト
http://d.hatena.ne.jp/takkaw/20080831/p2


こういうのって公式に取り込んでもらう方法ってないもんでしょうか？

>>729
core.quotepath = false
でいけます。

どこかに覗いたら勉強になるようなＯＳＳのＧｉｔレポジトリないでしょうかね？

gitだと、公開リポジトリは綺麗な歴史になるようにしてる
はずだけど、どういう勉強がしたいの? 自分で実験してみる
以上に勉強にはならないとおもうけど。

cloneしてから、一個一個コマンドを試していけば
いいんじゃないの?なんかダメなの?

>>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です

>>732
ｽﾚ違い

document.createElementで作ったinputをｊQueryで追加したんですが、
そのInputの入力Boxで文字列が選択できません。

これはなぜ？

どこの誤爆だ。

こんな所に・・・・
誤爆しました。失敬。

こんなところとは失礼だな君は

まあまあ、こんなところというのは良い意味で言ったんだよな、坊主

ついでだからgitについてもひとこと書いてけ、坊主

webdav経由の速度がsvn(mod_dav_svn)に負けるんだけど。
どこが早いだよ。ボケが。

とと間違えた糞がだった。gitだけに。

webdav経由なんて使ったことないな。速度って何の速度？　クローンじゃないよね？

webdav(笑)

>>741
ぎったんぎったんにしてやんよ

>>744
クローンだよ。
初回はやっぱりクローンだし。
LLのコード管理するならいいけど
中間コード生成する類のコードだと余計ファイルを一掃したくなるので
中央からクローンする頻度が上がる、クローンが遅いのは痛い。

零細企業の事情は知らんけど、そこそこの企業ならポート制限をかけてて
git用に別ポート開けろとかいやがられるので80ポートは開いてるからwebdav

>>747
だまってsvn使えばいいじゃない
gitのクローンって、リポジトリのクローンだよ？
速度を比べるのがおかしい

>>748
だな、速度を比べるのならsvnではr1からHEADまで全履歴を取得させて計測すべき。

>>748
たしかにsvn使う方がいいですね。そうします。

中央リポジトリだけsvnにしてもいいんだけど
それだとブランチ毎にcloneしないといけないっていうのが使いにくい。

Linusさんが作ったわけだから、中間コードを生成するようなものにも
利用してるはずで、多分私の運用方法がまずいと思うんだけど。
git系の解説書見てもよく分からん。

>>747
＞中間コード生成する類のコードだと余計ファイルを一掃したくなるので
＞中央からクローンする頻度が上がる、クローンが遅いのは痛い。
中間コードの生成とクローンの頻度に何の関係があるの？ ignoreとかmakeとか使えないの？
てかクローン（全履歴取得）は最初だけでその後はフェッチ。中央扱いの場所へのコミット頻度が
高ければ、必然的にフェッチする頻度も増すだろうが。

社外とクローズドなソースコードのやりとりするなら会社責任者の認証を受けるべきだし、
そんならちゃんとした手順踏んで相手方とトンネル掘るなりしてsshでやるべきじゃないかと思う。

件の中間生成物を掃除するために、リポジトリまるごと"rm -rf *"で闇に葬ってから
"git clone"してたりするんでないかと。

うわー

普通中間生成物削除する何らかの手段用意するよなあ。
Makefileのcleanターゲットとかさー

んだよそんな低レベルうんこ野郎が、糞だのボゲだのってDISってたのかよ。

rm -rf * して git checkout . はたまにやるな
早いし

"git clean -dfx"とか使わずにcloneし直して遅い遅い言ってる訳か。

>>750
ブランチごとにcloneって意味がわからん
git-svnは普通にSubversionのブランチも追いかけられるぞ？

>>747
UNIX系の環境だったら .gitをコード生成するディレクトリの外に
置いてsymlink貼って使うとか、symlinkが使えない環境だったら
webdavサーバからclone --mirrorした(ローカルの)リポジトリから
git clone -s して使うとか、いろいろ回避策はあるでしょう。

git clean知らなかった。便利だ。

1週間くらい前からライブラリはわりとできた気がするのだがGitHubで公開する勇気が出ない
めちゃくちゃ緊張して手が震えて駄目だ

公開することにした理由って何？

>>761
だいじょうぶ、反響が皆無で逆に落ち込むから。
よっぽどインパクトのあるものかライフチェンジングなもの、もしくは宣伝しまくって煽ったりしない限り、
オープンソースソフトウェアの影響は徐々にくるものだから、気楽にやったほうがいいよ。
で、なにつくったの？

>>761
アドバイス求めたら結構くれるよ

バイナリの場合は公開時の品質で悩むのもありだが
ソースつきなら
「俺はここまでやって方向示したのであとは凄い人が続きおね」
という思考で世間様にブン投げてOK

放っておけば誰かが使ったり誰かが紹介したり
もっといいものが出て忘れ去られたり
フォロアーどころか類似品すら出ずにカテゴリごと忘れられたりする

きっと世の中には、とんでもなく使いやすくて斬新なアイデアかつ生産性の高い
ソフトウエア（の前身）たちが今日も日の目を見ないままひっそりとどこかにいるんだろうなあ
そういう革新的なソフトたち発掘するネット界の冒険者っていうのもおもしろそうだなあ

という電波をいましがた受信した

なぜかネットハックというゲーム名を思い出した

過疎ってるからメモでも各課。

masterからtopicへの差分が見たい
git diff master..topic
ただこれだとmasterが成長するにつれて差分も増える（topic放置でも）

git diff master...topic
こうすると、topicに枝分かれした時点でのmasterからtopicへの差分が表示される
つまりmasterって指定してるけど、実際使われるのは以前のmasterのある固定のポイント
なので「んでtopicってどんだけ何かやったの？」ってなった時に安定してdiffが取れる。

>>767
あれ？逆じゃない？
＞masterからtopicへの差分が見たい
のなら前者が良さそうな気がするんだ

git diff master..topicはtopicブランチだけがもってるコミットを表示せよ
git diff master...topicはmaster、topicだけがもってるコミットをそれぞれ表示せよ
だと思ってたんだけど俺の勘違いか

ん？何言ってんだ俺
途中からgit logの話になってるな。くそったれ
>>767の言うとおりだよちくしょう

ブランチ毎に文字コード変えれたりしますか？

エリック・レイモンドがメンテナに加わったんだね

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を使っています。

正しく動かすにはどうしたらよいものでしょうか？また、原因としてはどこを疑ったものでしょうか？

ログをUTF-8で入れた他のgitのリポジトリで試したところ同じ問題が起こり、git-svnは関係ないようでした。

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

他のユーザーの方の環境できちんと動いているかお聞きしたいところです・・・

うんこはevilだからな

>>772
git help log のDISCUSSIONに書いてあるけど、commit logは
非NULのシーケンスとして解釈せずに格納してあるので、
grepする時にUTF-8に変換しようとして失敗してるんじゃない?
git help logの末尾の方には、commitした時にi18n.commitencoding
の値を記録している、と書いてあるけど、この値と実際のcommit log
の文字コードが一致していない、とかね。

>>774
別にうんこじゃなくてもいいんですがｗ

>>775
git log --pretty=format:"%s %e"
で調べた所特にエンコーディングの記述はなく、
ログ自身はUTF-8であらかじめ入れてあるので、
git log をリダイレクトでテキストに出力した所、ログ自身は予想どうりUTF-8Nでした。

cygwinのときだけデフォルトの文字コードが一致しない？ということがあるのかなあ

LinuxでOKで、cygwinで問題というのが気になるところです・・・。

"command line," とか "illegal byte sequence"でgitのソース検索したけど該当箇所でてこん・・・

illegalなんちゃらって多分EILSEQをstrerror()に渡して得られるメッセージ
だと思うけど

>>778
ああっと書き忘れてた、google code searchとかもついでに見てて、
EILSEQがひっかかったんでもgrepしてたんだけどgitソース内には見当たらなかった。
他の問題なのか・・・

それはlibiconvが出してんでしょ

TortoiseGitでSVNのリポジトリ使うのってどうやるの？

git pull する時に、origin/masterのHEADではなく、過去のコミットを指定して行うことはできますか?

>>782
git pullはsvn updateみたいにHEADをコピーしているのでなく、過去の履歴も
含めて全部引っぱって来ている．　のでpullしたあと作業ポイントをcheckout
コマンドで指定する。

1) そのコミットがすでにブランチになっていれば

git checkout <branch>

2) ブランチになってなかったら

git checkout -b <new_branch> <start_point>

<new_branch> はブランチ名
<start_commit>は選択するコミット


これ、gitのtutorialだけ見てたら分からなかったんだけど、SVNと比較するこの
tutorialを見たら分かった。

GIt - SVN Crash Course
http://git.or.cz/course/svn.html

>>783
サンクスです。それでいかせていただきます。

cvs,svnを使ってた人にとっては
git clone で落としてきた.gitは
CVSや.svnと同じようなものと思いがちやね。

>>747を見てバッカじゃねーのとか
思ったけど意外にこの勘違いを抱えたまま
毎回.gitを消してcloneしなおしてる人いるのかね。

いるかといえばいるんじゃないか。CVSやsubversionでも
そうしてきた人にとってはコピーしてきたリポジトリまで
消しちゃう無駄よりも、「ちゃんと動くことが分かる」状態
に戻ることのほうが重要だもの。

分かりにくいと思ったのがcheckoutコマンドだな。　svnやcvs等の古典的な
checkoutコマンドとは随分意味が違う。　「ちゃんと動くことが分かる」状態に
どうやってもどせばいいんだろうと探している時、コマンドのリストの中の
checkoutコマンドの説明を見ようとは普通思わないんじゃないかな。　

resetも二つの意味含んでるっぽくてわかりにくいな
unstageと分けてもいいと思う

git checkout を使って ２つ前のコミットまで巻き戻したのですが、
git log すると一番最新のコミットと２番目に新しいコミットが見れなくなってしまいました。
もしかして、checkoutはコミットしたものを取り消してしまう危険なコマンドなんでしょうか？
最新のものに戻したい場合はどうすればいいのでしょう・・
てっきりsubversionのrevertと同じようなものだと思って使ったのですが・・
gitのrevertはリビジョンを戻して新しくコミットしなおす感じのようですが、
最近のコミットを取り消さず、単純にファイルを巻き戻すだけのコマンドはないのでしょうか？
教えていただけると嬉しいです。

>>789
ここまで的確に逆のこと言ってると釣りに見えるな。

git checkout HEAD~2 とかやったのなら、名無しブランチに居るだけだから
元のブランチをcheckoutすれば元どおり。

git revert は指定したコミットを逆パッチしたコミットを作ってくれる。
後戻りはしない。

当たり前にドキュメント読んだほうがいいよ。Subversionとは概念が違う。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html

タグとブランチで同じ名前のがある時にタグのfoo、ブランチのfoo
という指定はできるのでしょうか。ただfooとだけ指定すると
warning: refname 'foo' is ambiguous.
リポジトリはcvsimportで作ったもので、ファイルによってfooが
ブランチの場合とタグの場合があるためにこういう状態になって
います。

>>790
レスありがとうございます。
自分がやったのは
git checkcout 862ed98d03863a826dca3246ee61d54264acae57
のような感じなんですが
あげて頂いたドキュメントを見ると、checkoutの説明のところに
「また、これが危険なコマンドであることも知っておかねばなりません。」
のように書かれていました。
やはり最新のコミット自体が消えてしまったように思えるのですが・・

コミットはなかなか消えない。
その下に、
>削除したブランチへのコミットや --amend コミットで上書きされた元のコミットでさえも復旧することができます
って書いてあるよ。

>>791
ローカルブランチはheads/foo、タグはtags/fooで明示的に指定できますよ

>>792
reflogというものがあってだな

>>792
＞ 「また、これが危険なコマンドであることも知っておかねばなりません。」
の部分は作業ディレクトリの情報が消えて、最新のコミットに戻されたって話だよ。

俺はgit以外のvcsをよく知らないけど、
subversionでも、レポジトリと個々人の作業ディレクトリってあるんだよね？
上の話は作業ディレクトリがレポジトリに戻されちゃって、
あなたの作業は消えましたよ、って話だから危険って書いてあるんじゃないのかしら。

>>789は最新のコミットと２つ前のコミット間の、あるファイルのdiffでも見たいの？
そうなら、
git diff HEAD~2 -- (あるファイル)
っていうのはどう？
どうしてもcheckoutしたいならcheckoutした後、
git diff master.. -- (あるファイル)
でもいい

>>792
あ、それと言うの忘れてた。
＞ git checkcout 862ed98d03863a826dca3246ee61d54264acae57
なら、>>790も言ってるけど一時的に別のブランチにいるよ。
git branchしてみれば、今までのブランチと別のブランチにいることが分かると思う。
git masterとかやれば元に戻れるんじゃないかな。
元がmasterなのかは知らないけど。

色々レスありがとうございます。

状況としては、

最近のコミットに
49qayt928t4ht2
と
goghpghr9g9grh
というのがあったとして(文字列は適当です)
49qayt928t4ht2
が最新なのですが、一つ前のgoghpghr9g9grhに戻したいと思い、
git checkout goghpghr9g9grh
としたら、git log しても最新の
49qayt928t4ht2
が表示されなくなり、49qayt928t4ht2のコミットが消えてしまったように見える、
また最新の49qayt928t4ht2に状態を戻したくても、戻した方が分からない、といった感じだったのですが
git reflog と git resetのおかげでなんとかなりました。
勉強になります。ありがとうございました。

>>799
checkout直後なら以前チェックアウトしていたコミットがORIG HEADに格納されてるよ

ORIG_HEADってマージのときに使うものかと思ってた
あれ？MERGE_HEADだっけ？

>>792
色々と突っ込みたい所はあるが、とりあえずチュートリアル読めば？

>>799
git resetを使う状況じゃない。まずは>>798の内容を理解しよう。

git の branch コマンドは他のVCSみたいな、いわゆる枝(branch)を作るコマンドじゃないことを理解した方がいい。
単に自分のいる点に目印の旗を立ててるだけ。
commitやreset等で自分が動けば旗も移動する。

>>804
これの"create"は「作る」という事ではないのですか？

$ man git-branch

...
NAME
git-branch - List, create, or delete branches

>>805
まあ論理的には「作る」と考えて良いんだけど、、、
内部的には複数のコミットから親として参照されてればそれはブランチと言える
というぐらいで、特にbranchコマンドを使わなくても、ある履歴の途中の位置を
checkoutして何かコミットすれば分岐になるし、commit --amend とかで
やり直ししても以前のコミットと新しいコミットは分岐してる。
ただこの場合古いコミットは一見して行方不明になるけど、branchコマンドは
そこに旗を立てて移動しやすかったり自動でGCされないようにしたりしてる感じ。
reset とかいろいろ試してるうちに内部構造が分かるとそう思うようになったかな。

各コミットは親を記憶してるから点から親を遡ることで枝を表現できる
ただ子の記憶は無いから自分の子供がどうなったかを辿る簡単な手段は無い
checkout等で移動してコミットが消えてるように見えるのはこの為

>>805
自動更新してくれるタグとおもえばよいよ

実はCVSでも似たようなことになっているんだけど、
自動GCがないということと、リポジトリの実装がファイル
単位なのでcvs adminコマンドで実現しようとすると1コミット
に関連するファイルに比例して面倒になる、という点が大きく違う。

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 → 成功

試行錯誤してたらローカルの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経由だと最後の方法しかダメ？

git svn clone svn+ssh://localhost/var/svn/project2 に
--trunk trunk オプションを適用したらどうなる？

>>812
レスありがとうございます。
次の2つが正しく動作するのを確認後、
$ svn co svn+ssh://localhost/var/svn/project2/trunk project2
$ git svn clone --trunk trunk file:///var/svn/project2

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

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

それなら -s をつけた場合も二回実行すればいけるかと、試したんですが二回目も失敗します
二回目は「error: git-svn died of signal 13」だけが表示されます。

Subversion のリビジョン番号が大きいと git svn clone が失敗するので、git svn fetch を使うと良い | cooldaemon's memo
http://cooldaemon.tumblr.com/post/71989299/subversion-git-svn-clone-git-svn

ローカルに作ったSVNリポジトリのHEADはリビジョン1なんですが、
上のサイトを参考に、git svn clone に失敗したあとにできたディレクトリに移動したあと
git svn fetch を実行したところファイルを取ってくることができました。

基本を教えてください。自前のプロジェクトをgithubに上げました。

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

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

ググってもいまいち飲み込めず・・・用語が難しくて理解しづらいです。

>>815
よくわからなかったら、既存のものをforkしたのでなければ、
bitbucketを使いましょう。

>>815
はい。正しいです。ブランチは新しい機能とメインの開発を分けて開発したい場合に使ったりします。
ローカルリポジトリ内で完結するので新しくフォルダをつくる必要はないです。branchとcheckoutコマンドでいろいろ遊んでみるとよいかも。

質問があります。(スレ違いでしたらすいません)

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

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

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

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

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

どうかよろしくお願い致します。

>>818
そのメッセージはマージ対象のブランチと現在のブランチが分岐してるよ、
って教えてくれてるんだけど、git-svnでもそれ出たっけな？
それにgit pull って、git-svn では使わないよ？

実際、svnのことは一旦忘れて、ドキュメントちゃんと読んだ方がいいよ。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html
大体一緒でしょ、っていうつもりでノリで触ってるとかえって回り道。

>>816
いえ、githubにしろって言われたもので仕方なく・・・

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

>ローカルリポジトリ内で完結するので新しくフォルダをつくる必要はない
ということは、checkoutするとブランチ間で異なるファイルがごっそり
差し替えされるということですね。試してみます。

てかさ、ドキュメント読まないやつ多すぎだろ。
何回ProgitとatwikiのURL貼らせんだよ。

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

たいして時間かかんないから、ドキュメント読もうぜ。Progitも公式チュートリアルも
親切丁寧に書いてあるから。はあはあ。

Subversionのブランチとタグが要らない混乱を生んでいる気がする。
CVSからさわっていれば、ブランチもタグもすんなり理解できるのだが。

>>819
>>821
>>822
819 さんに教えて頂きましたドキュメントなどを参考して、ローカル環境を戻してみます。
git svn rebase とするべきところ、ついつい、git pull と打ってしまう私が悪いんで。
また、さっきもやってしまって、マージできないとエラーが出たソースを元に戻していました。

質問です。

＜環境＞
$ uname
CYGWIN_NT-5.1

$ git --version
git version 1.7.0.4


歴代のコミットの状態を別のディレクトリへcheckoutできないものでしょうか。
今は、コミットIDの一覧からすべてをtar ballに吐き出して全部展開しなおす、
という手順をとっています。
もっと楽な方法(git clone [commit ID]とか)ご存知ではないでしょうか。

>>824
git-checkout-indexでできるよ

$CHECKOUT_ROOTの下に、各バージョンの短いハッシュの名前の
ディレクトリで展開するone-liner
git log --format=%h |while read h; do git archive --format=tar --prefix=$h/ |gtar -C $CHECKOUT_ROOT -xf -; done

各ディレクトリでもgitの操作をしたいならgit clone -sでリポジトリを
作ってからそこでcheckoutするようにしたらいいと思う。

>>825
ありがとう。svn exportというのは意図したコマンドのようなのですが、
git-checkout-indexのヘルプにはコミットID指定の引数が見当たらないような。

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

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

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

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

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

有難う。楽しかったです。

git commit -m c1
git commit -m c2
git commit -m c3
としたときの次のコミットを c3 に混ぜるには
git commit --amend
ですが、c2 に混ぜるにはどうやるんでしょう？

>>828
ttp://progit.org/book/ja/ch6-4.html

>>829
そのサイトを参考にやったらなんとかできました。ありがとうございます！
一応、自分用の実験メモを貼っときます。
$ echo x > x1.txt; git add .; git commit -a -m c1
$ echo x > x2.txt; git add .; git commit -a -m c2
$ echo x > x3.txt; git add .; git commit -a -m c3
c2 に含めたい作業分を c4 としてとりあえずコミットする(コミットしないと git rebase できなかったので)
$ echo x > x4.txt; git add .; git commit -a -m c4
c2 が何個前か確認すると3つ前だとわかる
$ git log HEAD~3..HEAD --oneline
e4b2fdb c4
cf77615 c3
09e1d42 c2
それを引数に git rebase -i を実行する
$ git rebase -i HEAD~3
エディタが起動して c2 c3 c4 の順に出ているので下のように c4 の pick を squash に変更して c2 の直後に移動させて終了すると
pick 09e1d42 c2
squash e4b2fdb c4
pick cf77615 c3
再びエディタが起動して c2 と c4 が出てくるのでコミットメッセージを調整して終了する。
再び確認するとc2とc4が一緒になっていることがわかる(コミットメッセージを c2c4 にしたので)
$ git log HEAD~3..HEAD --oneline
0fec832 c3
53d09e5 c2c4
61b0400 c1

rebase -iを使いまくる快感を覚えるとgitから逃れられなくなる。

>>827
ブランチを作ったりrebaseしたりすると使わなくなるaliasだと思う。

TortoiseGitでSVNリポジトリを使うのってどうやるんですか？

>>833
ここはLinux板だからプログラム板行った方が良いんでない？

というかTortoiseSVN使えよ

>>833
TortoiseGitにgit-svn機能が追加されたのは0.8.1.0からだそうだが、
あなたのバージョンはいくつなわけ?

>>834
ム板にgitスレがない
つーかなんで>>1はここに立てた…？
リーナスが作ったからか。そうか。

git log --graph使いやすい。
msysgitのgitkは文字化けするから助かる

>>837
2007年の時点だと、Linuxでしかまともに使ってる人居なかったんじゃないか

>>837
ム板にSVNならあるよ、ってこっちにもあるね。

とあるファイルをレポジトリに追加しようと思って、git add File
ってやった後、コミットする前にgit checkout -f 〜ってやったら、
当然追加したFileは消えてるよね。＼(^o^)/

これって、復活させることは無理？
要するに、消えたファイルをサルベージしたいんです...(T^T)

forceって指示出してるからねぇ…

あきらめて作り直す....べきですか
add *.cs
なんて一括で追加したものだから...
いい週末になりました。(゜Д゜)

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

$ git init; touch .gitignore; git add .gitignore; git commit -m 'init'
Initialized empty Git repository in /home/a/tmp/test-git/.git/
[master (root-commit) 8f89495] init
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
$ echo hogehoge > fuga
$ git add .
$ ls
fuga
$ git checkout -f master
Already on 'master'
$ ls
$ LANG=C tree .git/objects
.git/objects
|-- 82
| `-- e3a754b6a0fcb238b03c0e47d05219fbf9cf89
|-- 8f
| `-- 894951217914f4a29681fba7f7917acc034322
|-- e6
| `-- 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
|-- e9
| `-- bc11025c28829eedf6d30cd3b65628648cad5f
|-- info
`-- pack
$ git show e9bc11025c28829eedf6d30cd3b65628648cad5f
hogehoge

>>844
そっか、indexに入れたのが残ってるのか！

>>843
＞いい週末になりました。(゜Д゜)
サルベージがんばれ！

>>844-845
ありがとぉ〜〜。

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

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

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

あああ・・・
ディレクトリ間違ってGITROOTで

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

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


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


さすがにこれはもうアウト？

$ rm .git/index
$ git reset

でもだめだ…

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

おろろーん

xargsってこわいなやっぱ

っ「Daily backup」

うん。
途中まではサーバリポジトリにあったから、途中の履歴とブランチは諦ましたとさ。

あるプロジェクトでgit使い始めたんだが、その時点より古いコード一式が出てきた。
これを、過去の履歴として最初のコミットより前に登録することってできる？

>852
その古いコードからはじまる歴史を作るのが良いんじゃね。
その歴史をもったリポジトリを正にしてしまう。

あとからあとから、遺産が見つかるのよ。
でも、歴史はある時点のを基点として、進んでいってる。
つまり、遺産が見つかる度にリポジトリを作り直すってこと？

>>854
過去を改竄した上に、現在に至る道筋を全て書き換えるのだから、そうするしかないね。

ただ歴史の参考書として使うのが目的であれば、遺産専用のリポジトリを作って、
現実の流れとは切り離してみたら？

>>854
ちとめんどいが、リポジトリをまとめることできるよ

なんでその「遺産」とやらをリポジトリに入れなきゃいけないんだろ。

歴史的価値があるからだろ。

tar.gz とかで置いとくだけじゃだめなん?

blameしたりとかね

別のリポジトリかブランチ用意して時間を遡るようにコミットすればいい。
起点のあやふやなリポジトリなんてあっちゃいけない。

cvsがimportにタイムスタンプを保存してくれるんで、それを経由してならやったことがある。

>861
具体的には、git commit を使うの? それとも違うコマンド?
パッチ管理システムのgitが過去に向かって遡るように
できるとするとどのコマンドを使うのだろか。謎だ。

>>863
古いソースのアーカイブとかが見つかったのなら、その時点のコミットまで戻って
ソースを展開してコミット、で続きはrebaseで改竄、かな。
次のコミットのコンフリクトが激しい場合、そのコミットはresetで無理やり
作ることになるかも。

rebaseの手間や与える混乱を考えたら、川の字のような分断されたシリーズで
まとめておいて、始点終点の接続をtagでわかりやすくしておくのが無難じゃ
ないかな。

古いソースコードが小出しに出てくるって、どういうシチュエーションなんだ

web系の本番環境にCVS/, .svn/を置けないね、ってな話？。

>>866
今まで git で管理されていなかったプロジェクトを引き継いで、引き継いだ時点から git で管理しています。
# ので、歴史は進んでいます。

しかも圧縮されたソース一式を、メールでやりとりしていたという状況があって、
それが、後から後から「XX月XX日時点のソースはこうでした」なんて送ってくるのです。
大抵そのときは、「XX月XX日時点では問題は無かった」なんて言われるもので、diff もとりたいわけです。
他人の歴史を取りこめる git なら、なんかできるんじゃないかな、と思ったのです。

>>868
そっか、、、大変だね。
俺なら、過去専用リポジトリを作って、けっこう真面目に歴史つくりなおすと思うな。
reset、rebaseがちゃんと使えるようになれば、そんなに面倒でもないし、
歴史の改竄はたまにやるので、慣れてる。

ただ、差分見るだけだったらgitじゃなくてもdiffするだけでも取れるし、
とりあえずgitの使い方を学んでみたらいいと思う。

hgはcommitに--dateオプションがあって任意の日時が指定できるんだけど、gitの場合どうするんだろう？

>>870
gitにも同じオプションあるよ

.>>870
試してないけど、git commit にも同じ --date オプションがある。

>>871-872
Thanks. 1.7 から？
http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt

すいませんお聞きしたいのですが、
レポジトリ名の変更ってどうすればよいのでしょうか？

/home/ore/project というレポジトリを
/home/common/project にクローンして、
/home/common/project の方をorigin にして
/home/ore/project の方は ore という名前のレポジトリにしたいんです。

今は /home/ore/project が originになっていて
pushとかcloneで originはすでに存在しますみたいなエラーが出ます。

どなたか教えていただけると幸いです。

>>874
リポジトリの名前というものは無いのでディレクトリをリネームしてOK。
あとgit-remoteのドキュメントを読めばわかる。Pro Gitやatwikiあたりも。
http://www.kernel.org/pub/software/scm/git/docs/git-remote.html

>>リポジトリの名前というものは無いのでディレクトリをリネームしてOK。

あれ、すいませんなんか勘違いしてるのかもしれないのですが、
じゃあ例えば
/home/dareka/project
というレポジトリがあったとして、
/home/ore/project　を /home/dareka/project にpushするときは
git push dareka
みたいにすることができて、
この場合のdarekaがレポジトリ名だと思ったんですが、違うんですかね？
こういうことがしたい場合はどうすればよいのでしょう？

>>876
勘違いとかじゃなくてドキュメント読まないと分からないよ。
それはリモートの名前で、パスに別名を付けたようなもの。

なるほど。ありがとうございます。なんとなく分かりました。

すいません、追加でもう一つ質問したいのですが、
中央レポジトリの作り方を調べていて
http://d.hatena.ne.jp/hirose31/20090325/1237984133
このページを見たのですが、gitを使うユーザーに
中央レポジトリに書き込むgroupの権限を付与するということは、
その権限を付与されたユーザーは中央レポジトリの.git/objectsや.git/logs
のようなディレクトリを自由に編集・削除できてしまってことなんでしょうか？？

>>878
そうだね。つまり権限のある誰かがシェルを介して中央を破壊することは可能。
ただし分散してるからそう問題にはならない。
またリポジトリをsharedにしておくとFastForward以外はpushできなくなるので
通常の操作では破壊できなくなる。

自由にシェルを使わせるのが嫌ならgitosisという手がある。
てかこれもProGitに書いてある。いろいろ心配する前に一通りドキュメント嫁。

なるほど、ありがとうございます！
おかげさまでとりあえず最低限運用できるところまではいけましたので、
教えていただいたとおりこれからProgit読んでみようと思います。
ありがとうございましたｍ(_ _)ｍ

ぎっはぶが日本語化している……

gitってファイルのパーミッションは管理してくれないんですよね？
ファイルのパーミッション管理したいと思ったらcapistranoとかで
書いたタスクファイルをgitで管理するのがセオリーですかね？