984コメント325KB

git スレッド

■ このスレッドは過去ログ倉庫に格納されています

0001login:Penguin

2007/12/16(日) 18:40:39ID:GslAi8rs

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

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

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

0554login:Penguin

2009/11/22(日) 12:57:08ID:KnKStRKz

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

0555login:Penguin

2009/11/22(日) 18:25:36ID: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する方法や都度リモート先を変更するのは手順が煩雑になるため・・

0556552,555

2009/11/22(日) 18:28:42ID:AGTujtCR

間違えました。

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

0557552,555

2009/11/22(日) 19:14:14ID:AGTujtCR

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

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

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

0558login:Penguin

2009/11/28(土) 04:29:09ID:mXZ4Zywn

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

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

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

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

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

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

0559login:Penguin

2009/11/28(土) 20:11:39ID:xkqQAqqu

git checkout --ours --theirs

0560login:Penguin

2009/12/03(木) 20:30:50ID:lBf6Jtla

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

0561login:Penguin

2009/12/04(金) 13:36:14ID:F6K5uhGt

　-----B
/　\
-------A
　 \
　　---C
という感じで開発を進めていて、Bの変更はマスターであるAに頻繁にマージしている状態です。
Cで $ git pull A でマージして $ git push A とすると
To prevent you from losing history, non-fast-forward updates were rejected.
Merge the remote changes before pushing again.
といわれてしまう。
なんでnon-fast-forwardな状況なんだかよくわからないです。どうやったら直せるんでしょうか?

0562login:Penguin

2009/12/04(金) 22:38:29ID:8MryHyNF

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

0563login:Penguin

2009/12/05(土) 10:43:44ID:Pt8GWP/i

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

0564login:Penguin

2009/12/05(土) 13:58:28ID:dGM7vi/8

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

0565login:Penguin

2009/12/06(日) 00:13:42ID:O+n3DTMA

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

0566login:Penguin

2009/12/06(日) 03:51:03ID:3OwwH+xV

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

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

0567login:Penguin

2009/12/07(月) 12:28:13ID:XoL3Gt8w

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.

0568561

2009/12/07(月) 13:26:24ID:BLewJ948

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

0569561

2009/12/07(月) 13:34:18ID:BLewJ948

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

0570login:Penguin

2009/12/07(月) 14:54:49ID:XoL3Gt8w

>>569
git statusした時に
# Your branch and 'origin/master' have diverged,
# and have 1 and 1 different commit(s) each, respectively.
という感じで出るので、これで分かる。ただしgitのバージョンが古いとこれ出ない。
git show-branchも調べてみたらいいかも。あとgitkはそれなりに見やすいと思うな。

>>561
＞Merge the remote changes before pushing again.
これやってみればいいのに。mergeだけだとマージコミットだらけになっちゃうから、
rebase出来る時はrebaseした方がいいけどね。git pull --rebaseとか。

0571login:Penguin

2009/12/08(火) 01:34:52ID:JrbFTpX+

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

0572561

2009/12/10(木) 14:41:50ID:ZxyM+JCY

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

0573login:Penguin

2009/12/11(金) 09:24:45ID:n6TyF9bQ

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

0574login:Penguin

2009/12/12(土) 01:53:51ID:1uRf1xZK

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

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

0575login:Penguin

2009/12/12(土) 02:23:58ID:7I0ALriM

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

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

0576login:Penguin

2009/12/12(土) 14:40:22ID:0trcq50X

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

0577login:Penguin

2009/12/12(土) 15:31:09ID:1uRf1xZK

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

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

0578login:Penguin

2009/12/12(土) 15:35:54ID:1uRf1xZK

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

0579login:Penguin

2009/12/12(土) 18:45:28ID:7I0ALriM

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

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

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

0580login:Penguin

2009/12/12(土) 19:41:26ID:91i8JXzY

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

0581login:Penguin

2009/12/13(日) 04:59:08ID:XTGOd8wr

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

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

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

0582login:Penguin

2009/12/13(日) 12:05:06ID:eLNfVime

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

0583login:Penguin

2009/12/13(日) 21:39:57ID:MfgUdwK5

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

0584login:Penguin

2009/12/13(日) 22:56:38ID:hWQ7uDdJ

だよね

0585login:Penguin

2009/12/13(日) 23:48:27ID:yRHWt0hz

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

0586login:Penguin

2009/12/14(月) 00:06:09ID:iC7LD6wI

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

0587login:Penguin

2009/12/14(月) 00:12:42ID:1YNrTAVE

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

0588login:Penguin

2009/12/14(月) 00:21:12ID:MiMO4S1u

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

0589login:Penguin

2009/12/14(月) 00:50:41ID:uqSDssQD

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

0590login:Penguin

2009/12/14(月) 20:21:03ID:9KU3MLe4

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

0591login:Penguin

2009/12/14(月) 22:02:14ID:iC7LD6wI

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

0592login:Penguin

2009/12/15(火) 00:21:21ID:uU/CeyJd

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

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

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

0593login:Penguin

2009/12/15(火) 04:59:39ID:pR/bRTj/

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

0594login:Penguin

2009/12/24(木) 15:20:36ID:v3JWri2J

1.6.6 released

0595login:Penguin

2009/12/25(金) 21:55:28ID:lY3loZi6

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

0596login:Penguin

2009/12/26(土) 00:20:32ID:EUZh5OCV

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

0597login:Penguin

2009/12/26(土) 06:40:51ID:SkSud091

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

0598login:Penguin

2009/12/26(土) 06:42:53ID:SkSud091

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

0599login:Penguin

2009/12/26(土) 10:39:25ID:AQehkmKr

おーでかーけでーすかー

0600login:Penguin

2009/12/26(土) 12:12:59ID:Z6Z05dDL

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

0601login:Penguin

2009/12/29(火) 01:24:35ID:AAGVKxmF

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

0602login:Penguin

2009/12/29(火) 14:12:54ID:utuwRMGk

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

0603login:Penguin

2009/12/29(火) 18:19:26ID:erZVRnS3

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

0604login:Penguin

2009/12/30(水) 07:38:54ID:kfBW1mPl

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

0605login:Penguin

2010/01/08(金) 12:31:36ID:S57JTlxp

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

0606login:Penguin

2010/01/09(土) 10:57:40ID:3So5fkbw

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

0607login:Penguin

2010/01/12(火) 19:43:07ID:2XlpNrfT

githubみたいに、git archiveで生成するアーカイブに
コミット名を入れたいのですが、みなさんはどうやって取得していますか？

知りたいコミットがHEADとした場合、bashでは
VER=`cat ".git/\`cut -d \ 　-f 2 .git/HEAD\`"`
でコミット名が取得されるのですが、
Makefile内だとうまくエスケープ？されなくて困っています。
他の方法があればそちらで試してみたいと考えています。

ちなみに、Makefile内では
@VER=$(shell cut -d \ 　-f 2 .git/HEAD)
@VER=$(shell cat .git/$(VER))
echo $(VER)
としているのですが、変数VERが空になってしまいます。

0608login:Penguin

2010/01/12(火) 23:43:38ID:914bGyNn

git describe --always

0609login:Penguin

2010/01/13(水) 05:50:58ID:+l7m8J7G

git rev-parse HEAD

0610login:Penguin

2010/01/13(水) 09:58:54ID:/kr/i6EO

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

0611login:Penguin

2010/01/18(月) 10:24:04ID:xAKlwsjN

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

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

0612login:Penguin

2010/01/18(月) 11:48:43ID:9pALEWP2

ignore すれば？

0613login:Penguin

2010/01/18(月) 11:58:05ID:xAKlwsjN

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

0614login:Penguin

2010/01/18(月) 20:36:24ID:KAj8+0o6

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

0615login:Penguin

2010/01/18(月) 20:43:21ID:2FuAr7Gb

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

0616login:Penguin

2010/02/04(木) 11:09:26ID:5W3FJugT

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

0617login:Penguin

2010/02/04(木) 11:11:53ID:CYNiw1E3

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

0618login:Penguin

2010/02/04(木) 13:34:55ID:YQOQkcZC

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

0619login:Penguin

2010/02/04(木) 14:30:46ID:5W3FJugT

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

0620login:Penguin

2010/02/04(木) 17:54:59ID:5NWhCwR0

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

0621login:Penguin

2010/02/04(木) 19:37:14ID:YQOQkcZC

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

0622login:Penguin

2010/02/04(木) 19:39:44ID:YQOQkcZC

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

0623login:Penguin

2010/02/04(木) 19:55:52ID:gmC/Yryo

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

0624login:Penguin

2010/02/04(木) 20:47:50ID:JYXesGU0

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

0625login:Penguin

2010/02/04(木) 21:36:49ID:G2p82aGi

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

0626login:Penguin

2010/02/05(金) 00:04:47ID:+YPRuxoa

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

0627login:Penguin

2010/02/05(金) 01:55:01ID:CLmEj5oN

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

0628login:Penguin

2010/02/06(土) 00:46:55ID:44qJRz29

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

0629login:Penguin

2010/02/09(火) 20:22:37ID:RAlUQWhi

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

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

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

0630login:Penguin

2010/02/09(火) 20:36:57ID:b7GskCpL

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

0631login:Penguin

2010/02/09(火) 20:39:16ID:acViODVs

ﾆﾔﾆﾔ

0632login:Penguin

2010/02/09(火) 20:39:37ID:nKVKxkV8

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

0633login:Penguin

2010/02/09(火) 20:47:12ID:9V49chdu

screen と emacsclient使え。

0634login:Penguin

2010/02/10(水) 09:43:04ID:QkCzSUH3

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

0635login:Penguin

2010/02/10(水) 10:00:40ID:0TBtUf8g

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

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

0636login:Penguin

2010/02/10(水) 15:21:40ID:M9UhD/wS

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

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

0637login:Penguin

2010/02/10(水) 15:26:10ID:3rYFILyb

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

0638login:Penguin

2010/02/10(水) 15:31:20ID:M9UhD/wS

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

0639login:Penguin

2010/02/10(水) 15:33:25ID:uKVeMcIn

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

0640login:Penguin

2010/02/10(水) 15:43:03ID:9JULZJQU

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

0641login:Penguin

2010/02/10(水) 16:33:53ID:wST9AMIH

ふーん

0642login:Penguin

2010/02/11(木) 11:44:58ID:yw+dRYs8

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

0643login:Penguin

2010/02/11(木) 12:45:14ID:XV6xszzu

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

0644login:Penguin

2010/02/11(木) 15:02:11ID:nZMD/n4Y

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

0645login:Penguin

2010/02/11(木) 15:10:50ID:yJW9hFuf

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

0646login:Penguin

2010/02/11(木) 15:55:14ID:WaojUPKf

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

0647login:Penguin

2010/02/11(木) 17:30:48ID:aEGTGT/7

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

0648login:Penguin

2010/02/11(木) 19:24:12ID:oAJQYaS+

どこのblogかkwsk

0649login:Penguin

2010/02/11(木) 20:12:33ID:jeJxZddW

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

0650login:Penguin

2010/02/11(木) 22:27:09ID:71QNNVeu

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

0651login:Penguin

2010/02/12(金) 01:58:47ID:hFHmJq9f

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

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

0652651

2010/02/12(金) 02:00:25ID:hFHmJq9f

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

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

0653login:Penguin

2010/02/12(金) 08:54:33ID:hx+CbuVO

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

0654login:Penguin

2010/02/12(金) 11:50:19ID:StLEjzjs

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

■ このスレッドは過去ログ倉庫に格納されています