Git 4

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/

◆前スレ
Git 3
http://toro.2ch.net/test/read.cgi/tech/1310403238/

◆関連サイト
Pro Git - Table of Contents
http://progit.org/book/ja/
Git入門
http://www8.atwiki.jp/git_jp/

◆過去スレ
Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/

◆関連スレ
バージョン管理システムについて語るスレ8
http://hibari.2ch.net/test/read.cgi/tech/1295493964/
CVS導入スレ〜 Rev.3
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
Subversion r14
http://toro.2ch.net/test/read.cgi/tech/1326806859/l50
【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 3
http://hibari.2ch.net/test/read.cgi/tech/1297704483/

◆関連スレ 別板
CVS 1.3 [UNIX板]
http://hibari.2ch.net/test/read.cgi/unix/1093611448/
subversion バージョン管理【サブバージョン】 [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1154701996/

◆関連書籍
Ｇｉｔによるバージョン管理
2011/10
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5

実用Ｇｉｔ
2010/02
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8

入門Git
2009/9
http://www.shuwasystem.co.jp/products/7980html/2380.html

入門ｇｉｔ
2009/08
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

bzr-git で快適 github 生活
http://d.hatena.ne.jp/methane/20111224/1324698755

GitユーザのためのBazaar
http://standing-shoebill.appspot.com/bzr-migration-docs/ja/survival/bzr-for-git-users.html

Bazaarスタートアップガイド
http://standing-shoebill.appspot.com/bzr-startup-guide/

Bazaarでござ〜る。猿でもできる分散バージョン管理“超”入門 (1/4) - ＠IT
http://www.atmarkit.co.jp/fjava/rensai4/devtool20/devtool20_1.html

Bazaarスレに貼る様子がないってことはただのアンチGitか

>>7
流石にそれは穿ちすぎだと思うぞ
subversionから何処に行こうか悩んでる層もあるだろうし、総合スレが無いんだから相互にテンプレでリンク貼るのは良い事だと思うんだ。

>>8
> 総合スレが無い

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

まあ、相互に張ることは俺も賛成だけど。

>>9
おお、あったのか俺の目腐ってるわ orz

Gitに限った話ではないですが、コミットメッセージに困っています。
よいコミットメッセージとは？どんなコミットメッセージを書けばよいのか？
先人の知恵を拝借したい。具体例つきで教えてくれるページがあれば紹介してください。

>>11
928 名前：デフォルトの名無しさん [sage]： 2011/10/18(火) 21:59:17.57
ずっと悩んでるんだけど、コミットメッセージに句点ってつける？


929 名前：デフォルトの名無しさん [sage]： 2011/10/18(火) 22:21:38.59
>>928
http://mercurial.selenic.com/wiki/ContributingChanges#Patch_descriptions
> lowercase summary line, no trailing period


930 名前：デフォルトの名無しさん [sage]： 2011/10/19(水) 00:25:26.56
ほほー、こんなガイドラインがあったんですね。基本つけない方向にします。

>>11
http://troter.jp/scmbc-201111-mercurial-introsession/#id23

gitblitをインストールしたんだけど、localhostからしか見れない。
server.httpBindInterfaceを静的IPに変えてもダメ。
PINGは通るし他のサーバーソフトの場合見れるから、
gitblit側の問題だと思うんだけど。
周りからでも見れる方法分かる人いますか？

firewallが遮断してるなんてことないよな

とりあえずログを確認してみたら？

うーん。ファイアウォールとかいろいろ外してもダメだった。
外部から接続すると「サーバーに接続できません」とでる。
ログにはなにも出ない状況。
自分からは接続できるし、ログも正常に出るってな感じ。

もう確認してるだろうけどFAQの上2つやってみてダメなら分からんなぁ
ttp://gitblit.com/faq.html

サンクス。そこ見てなかったから今度やってみる。

gitのリポジトリという用語について質問です。
リポジトリとはWork Tree（History）と同義なのでしょうか？
それともWork Treeを含んだもっと広い範囲を指す言葉なのでしょうか？

そしてリポジトリにインデックスとワーキングディレクトリを含むのでしょうか？

ベアレポジトリでググれ

>>20
git は詳しくないけど、一般的にバージョン管理ツールでは
・リポジトリ　今までにコミットした全バージョンが格納される倉庫
・作業コピー　実際に編集やコンパイルやテストなどの作業を行う対象
は対比される概念で、SVN などでは物理的にも分離されてるよね。

git では
・リポジトリと作業コピー (work tree) の間にインデックスがある
・物理的には、リポジトリもインデックスも work tree の .git ディレクトリに格納される
ってあたりがややこしいけど、概念的には分けて考えるべきだと思う。

msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！
http://d.hatena.ne.jp/nitoyon/20120221/msysgit_utf8

やっとかめ

うれしいわ

git と github の違いってなに？

cvswebみたいなgitwebってある？

Gitはソフトウェア。
githubはサービス。

>>27
ブラウザで見るだけならviewgitとかかしら?

>>27
「cvswebみたいな」をもうちょい詳しく
gitwebというプログラムはあるし、他にも類似のが3つ4つは(たぶんもっと)ある。

>>30
好きな子との差分をカラフルに見たりtarで固めてダウンロードしたり
コマンドラインだと面倒くさいことが出来る

(；´Д｀)ﾊｱﾊｱ

何ハァハァしてんのよ気持ち悪いわね、ブタ！

・リモートリポジトリのmasterブランチに間違ってpushしてしまった。
　これを取り消したいけど、どうしたらいいの？
　git push origin :master
　としたら
remote: error: refusing to delete the current branch: refs/heads/master
To [email protected]:myname/MyProject.git
! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to '[email protected]:myname/MyProject.git'
　といわれて削除できない。

・git mergeするときに、必ずrebaseしてからmergeするよう強制させたい。
　いい方法ありますか。
　たとえば git merge するときに、fast-forwardできなければエラーになるオプションとか。

>>34
git push origin master --force
git merge hoge --ff-only

>>35
朝早くからありがとうございます。あとで試してみます。

>>34
リモートのリポジトリにpush --forceはマナーがよくない
誰も見てないと確信できないならrevertした結果をpushするのが吉

> 37

失敗したリポジトリが唯一無二のリポジトリとせずに新しくリポジトリを作る手もある。
ってか、パスワードを埋め込んだりして、リポジトリをスキャンして書き換えると、
この手以外に思いつく?

gitgのファイル内容表示部で検索できないのが辛い
Ctrl+Fするとコミット一覧の検索欄に飛んでしまう

>>35
> git push origin master --force
これはこの通りでいけました。

> git merge hoge --ff-only
これはですね、問題がありました。
というのも、git merge hoge --no-ff をいつも使っていて、それだと --ff-only は使えないようなんです。
あたりまえっちゃあ当たり前なんですけど、successful git branching model を読んでからは
--no-ff を使うようにしているので、その上で必ずrebaseしてからmergeするのを強制することはできますか。
条件が後出しで申し訳ありません。

>>38
> パスワードを埋め込んだりして
・・・実はまさにこれをやっちゃったんです。お恥ずかしい。

RailsのGitHubリポジトリがハックされた件
https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57

github の mass assignment 脆弱性が突かれた件 - blog.sorah.jp
http://blog.sorah.jp/2012/03/05/mass-assignment-vulnerability-in-github

gitの問題じゃないじゃん

「githubを運用しているRubyOnRailsの脆弱性でRailsのリポジトリが（実証性証明のために）ハッキングされた」だな

gitだrailsだよりもrubyistとPHPerが仲が悪いという事を知って新鮮に思った
同じLL使い仲良くやれよ

>>45
Ruby使いは排他的だからな。
新鮮に思うようなことじゃないって。ｗ

>>46
初耳だな

>>47
PHP使いもPerl使いもJava使いもPython使いも
他の言語と併用することに抵抗がない人ばかりだよ。
Rubyだけだよ、単一言語に拘るのって。ｗ

ということにしたいのですね。

いや、Rubyistが色々と弱点が多いPHPerを一方的にdisってるだけじゃ…

安心と信頼のPythonなBitbucketをお使い下さい

>>50
この板でのことなら、今度その人にRubyを使っているなら必ず答えられるようなことについて聞いてみるといい
おそらく、なにひとつ答えられないから

>>45
別にPHPerはRubyを見下しては無いよ
ただRubyistがケンカ売ってくるから買ってやってるだけ

>>53
その二行、書いてて矛盾に気付かないのか？ｗ

どんな言語でも得意不得意あるでしょ

githubで言語別にソースコードを管理したいんですけど
どういう風に管理したらいいですか？

Java
|-リポジトリ１
|-リポジトリ２

Perl
|-リポジトリ１
|-リポジトリ２

こんな感じでやりたいんです

素直に考えれば、
https://github.com/username/Java_リポジトリ１
https://github.com/username/Java_リポジトリ２
https://github.com/username/Perl_リポジトリ１
https://github.com/username/Perl_リポジトリ２
こうだよな。

つまりリポジトリの名前の先頭に言語の名前をつけろってことすか？

>>57
そうだな。それか、
https://github.com/username/Java.git
https://github.com/username/Perl.git
にせざるを得ない。
リポジトリのグループに名前をつける機能みたいのがあればいいんかね

グループを作ってそこにリポジトリを入れられたり
せめてラベルをつけて管理出来る機能があればいいのにな
ほんとｋｓだないてゅｂ

既存レポジトリで親コミットのないコミットオブジェクトを作りたい時ってどうするのが簡単？

新しくリポジトリを作る

>>61
fetchかな

>>61
これでどうだろうか
git add .
git commit # いったんどこかのブランチにコミットする
git cat-file -p HEAD > foo # cat-fileの出力をファイルにリダイレクトしてcommitオブジェクトを得る
git reset HEAD^ # commitオブジェクトは手に入ったのでHEADはもう不要だから捨てる
(edit foo) # このファイルの`parent'行を削除し、コミット時刻を適当に変更する
git tag bar `git hash-object -t commit -w foo` # commitオブジェクトを格納しタグを付ける

commitオブジェクト手書きするのは面倒そうだからどっかにコミットしてそのオブジェクトを利用してみた
試行錯誤の結果自分はこれでうまくいっただけなので、なんかまずい点があったら指摘してくだしあ＞識者

>>63
こんな感じ？
cd ..
mkdir newrepo
cd newrepo
git init
touch .gitignore
git commit -m init .gitignore
cd ../oldrepo
git fetch ../newrepo

>>61
$ git checkout --orphan <newbranch>

>>61
$ git write-tree
<tree-id>
$ git commit-tree <tree-id> -m message
<commit-id>
$ git log <commit-id>

>>66
きたこれ

>>59
個人名じゃなく単にプロジェクト名とかでアカウントとってる人もいるな

複アカとってもいいの？

それアカウントじゃなくてOrganizationじゃないの？

gitで文字コードがsjis以外でしかも色々混在しているというような
場合はどうしたらよいでしょうか?

調べると
git config --global i18n.commitencoding euc-jp
git config --global i18n.logoutputencoding euc-jp
というような設定をするようにと書かれているのですが
このeuc-jpのところで指定できる文字コードのリストはありますか?
あとこれだけではa.txtはutf16le-bomでb.txtはsjisというような場合に
対応できないと思うのですが何か方法があるのでしょうか?

gitにとっちゃコミットするテキストがどのエンコードかなんて知ったこっちゃない

というかテキストのエンコーディングをいじられたらたまったもんじゃない

デフォルトじゃutf16は無理なんじゃ。

8bit系ならASCII部分が共通で通常の文字の範囲に制御記号が入らないかぎり
ファイル単位でのdiffやマージに問題はなさそうだが

ファイル名に日本語は使えますか。
windows、Macが混在しても大丈夫ですか？

すいません文字コードはUTF-8(BOMなし)かShift_JISしか使わなくて改行コードはLF市か使いません
Windowsにgitをインストールするとき、改行の件で選択する部分があるじゃないですか、
んで、推奨するところに最初からラジオボタンが選択済みになってますよね
あれはLFしか使わない場合は何にしたらいいのでしょうか？

今までgistなるものがあるのを知らずに、ファイル1つだけでもgithubを使用していました。
これをgistへ移すことはできるのでしょうか？

githubからforkしたポジトリを自分のローカルへCloneしました。
本家から差分をpullしてたところタグ情報がとれてないみたいなんですが、
何か方法がまずいのでしょうか？
ソース自体はちゃんととれているようです。

1. 本家 → fork → My Repo
2. My Repo → clone ローカル
3. 本件の差分 → pull → ローカル（この時点でタグが更新されない）
4. ローカル → push → My Repo

>>79
あんまわからんけどレスします。
man git-fetch の -t, --tags の説明に書かれている場合に当てはまっているとか。
git fetch --tags でいけませんかね？

お願いします助けてください
お客さんのソースコードを何も考えずにコミットをしていったのですが
コミットをした履歴というのはgit logでとれました
そして１０回コミットをしてるんですが
git checkout .　だと最新のコミットしたやつをしゅとくできますが
4番目にコミットした内容を取得したいのですがこれはどう書くのでしょうか？

…本当にやりたいことは取得ではないよな
4回目のコミット内容を画面に表示できればOKなわけではあるまい
（いや、それ見て目視の力技で修正コミット作るのかもしれないが）

4番目のコミットのハッシュで取れる

git checkout ハッシュですね！
たすかります！！！！！

おちつけｗｗｗそこｗ「とりあえずバックアップしとこ」でコピーを取るんじゃないｗｗｗ

何かとんでもないことになる前にgit stash saveを忘れるな

なんかハッシュを毎回手打ちするのって面倒くさいですよね
これを自分で名前をつけることって出来ないですか？
git checkout version1.0
git checkout version1.1
git checkout version2.0
みたいに

>>87
tagを使え

タグ使えよ

>>87
checkoutの-bオプションや、tagやbranch使う

よっし!!!!
おれの勝ち!!!

タグですか！ありがとうございます！
ブランチっていうのは
git branchでbranch一覧を出します
git branch testってやったらtestブランチが作れました
でもブランチって何をするものなのか分からず、ここで挫折して一時期引退しました

git なんて面倒なもの使わずに zip で固めるといいと思う。

zipなんて使ったら一発でstashもできないしbranch切れないしmaergeもrebaseもできないしpushもpullもできないし

でも4番目のコミットをすぐに取り出せるよ。tag だって好きなファイル名付ければいいんだし。きっと分かりやすいんじゃないかな。

もちろん、自分は普通に git 使ってるよ。でも、使えない人が無理に使う必要はないと思う。

しかし、もし同僚がそれだとzipに付き合わされる方は悲惨だな
無理にでも覚えさせたいところ

二カ所からだけソースにアクセスして編集する場面について質問します

パソコンaとパソコンbからgithubにおいてあるソースをいじろうとして、
パソコンaで作業したものをまずpushし、それをパソコンbでcloneで受け取ってからかなり編集しました
その後パソコンbの編集内容をgithubのソースにpushしました
ブランチは一切変更していません(masterのまま)

現在のgithubのデータをパソコンaに反映させるにはどういう手順を踏めばよいのでしょうか
それと、今後同じような処理をするのに便利な方法はありますか

その程度だったら
git pull remote master
でいいんでね？

>>97
git pull じゃダメでしょうか？

とりあえずなんか1冊読め、と言いたくなる質問だな。

>>100
まぁ、たしかに。
一冊読むだけで大分違うもんな。
Gitは、濱野氏のだけ読んだ

>>98-99
ありがとうございます。

>>100
実用gitを持っているのですが、pの索引にpullがありませんでした
勉強します

すみません
索引に"git pull"で項目がありました
失礼しました

Tortoisegitを使っていて質問があります
初歩的な質問で申し訳ないのですがローカルからGithubにpushするさい
foo.cpp bar ago Update foo.cpp [私のユーザー名]としてpushしたいのに
foo.cpp bar ago Update foo.cpp [Unknow]としてpushされてしまいます
Unknowではなくユーザー名を表示できるようにpushしたいのですが
設定を見ても見つからず四苦八苦しております
ご存知の方がいたらよろしくお願いします

>>104
git コマンド使えるなら、
git config --global user.name "John Lennon"
git config --global user.email [email protected]

ここ見ると MSysGit入れたらGUIで設定できるぽいよ。
http://d.hatena.ne.jp/tarurut/20110117/1295285155

>>105
ありがとうございます
おっしゃるとおりに試してみたのですがどうにもうまくいきません
自分の方でももう少し試してみます

>>80
サンクス！解決した！

>>106
MSysGitでコミットしたらどうなるとか、$HOME/.gitconfig みてみるとか。
オレ環境なくてわからんから、あとは、TortoiseGitユーザに任せた

>>107
結局なにが原因だった？

>>108
どうやら導入していたバージョンが相当古かったのが問題の一つのようでした
そのほかにもローカルリポジトリごとにユーザー名、Emailアドレスを変更するなど
細かな設定をいじる必要があったようです

ありがとうございました

解決しました。ありがとうございました。

このスレで回答してくれる人って
現場でgitをバリバリ使いこなしているのかな
すごい

複数のPC間でエロ画像管理してるニートかもよ

エロ画像管理でGitってどういう風にやんの
モザイク前・モザイク後？

ファイル名に特別な意味があるんじゃないか？
ランキングになってたり

間違えてコミットするべきでないときにコミットをしてしまいました
git add .
git commit -m "20130316"
これを取り消したいと思い
git reset HEAD^
ってやってMore?って聞かれたのでyを押してENTERキーを押しました
その後git logでログをみたんですが消えてないことを確認して、コマンドのミスに気づきました
改めてコマンドをgit reset --hard HEAD^と打ってみたのですがgit logでログをみても消えません
一番最新のコミットを消したいんですがどうやって消したらいいのでしょうか？

git commit --amend

問題発生！！！！！！！！！！！
ソースコードに自分でないてない謎の文字列がところどころに挿入されていた！！！！
やばい怒られる；；

<<<<<<< HEAD

=======
>>>>>>> parent of 2b1498e... 2013/03/15

git commit --amendもやってもだめです
どうやら壊れｍ下

>>118
コミットしたときにコンフリクトした的なメッセージが出ただろうが

>>118
的確なアドバイスじゃないと思うけど、まずはディレクトリをバックアップしてから…
% git checkout -f .
% git reset .
% git reset --hard (戻りたいcommit id)

てゆか、commitしてresetしただけでコンフリクト発生ってどういうこと？＞all

なんで来年の日付なんだ

>>118
>>116のコミット成功してる？
コンフリクトしてるならコミットできてないと思うけど。

>>112
オレは現場では、VSS(しかも6)とSVNしか使ったことない。
大規模(土方的)な案件って、大体それらなイメージ。
p4とかもあんのかな。

趣味のプログラミングでだけど
git使ってるよ

感銘を受けた自己啓発本の言葉.txtやらアプリケーションの設定とかはgithubで管理してるけど
プログラミングに関しては仕事のもの以外は人にコード見せたくないしコードあげたことない

あなたにとって今日が人生で一番若い日です

bitbucketはプライベートリポジトリ作り放題。

お金を銀行や郵便局に預けても
あなたのお金は増えません
将来の増税につながるだけです

デフレである現在はお金を使わなければ実質価値が将来増えます

見せたくない理由にもよるけど、膨大に存在するリポジトリから（github以外にもいっぱいあるよ）
あなたのコードが発見されるとか、
発見した人が何かに利用するとか、
連絡を取ってくるとか、
可能性が余りにも低いから気にした奴が負け

commitしたあとで以前のlogの一部を書き直す方法は？

>>132
git rebase -i

そしてreword

>>128
突然有料化になって取れなくなったら怖いので使ってない

予告もなしに有料化とな？
あなたの使ってるプロバイダは今この瞬間から料金が二倍になります。
2chへの書き込みは今この瞬間から100円かかります。

うん、普通にありえる話だね。

取れなくなるもリモートのはローカルのコピーだろ

github の opensource で作った repository って
特になにもしなければ自分以外は全員 read-only になる訳ですか？

そうよ

Collaboratorになりたい人は
どうやって作者に連絡取るの？

普通にメールとかでいいんじゃね。
PullRequestを送りまくっていればだんだん相手が面倒になって
追加してくれるってのがなんとなくGitHubっぽい

台無しだがいちばん多いパターンではある
そしていきなりmasterに追加される節操のないコミット

fork が branch みたいなもんだから
それもまた Git っぽい

テキストファイルの文字コードが
utf16とかだとバイナリファイルと認識されるみたいで,
git diffとか使っても
binary files a/hoge.txt b/hoge.txt differ
としか表示されないのですが変えられるのでしょうか?

はい

>>78
GitHubのインタフェースからはできないんじゃない？
少ししかないなら手で、山ほどあるならこういうのとか使って放り込むしかなかろうて。
ttps://github.com/defunkt/gist

>>144
変えるだけなら、.gitattribute に *.txt diff だけでいける。
これ、結構古い情報だから、いまは違うアプローチがあるかもしらんが …
ttp://stackoverflow.com/questions/777949/can-i-make-git-recognize-a-utf-16-file-as-text

>>147
どうもうまくいきませんね...
utf8やutf16のテキストをまともにgitで管理する方法はないはずはないと
思うのですが

>>148
「まともに」とは？
[.gitattribute]
*.txt diff
すれば、少なくとも binary files 〜 は出無くなるけど

>>149
git log -p
で文字化けします。
調べるとless.exeを置き換えて対処とか書いてあったりするのですが,
cmd.exeの都合なのかうまく表示されません

>cmd.exe
あー……
Windowsのコマンドプロンプトか
もともとUnicode未対応だな

理屈上は、gitが利用する外部コマンドが全部UTF-8なりUTF-16なりを解釈可能なら使えるはず

>>150
管理というか表示できてないだけですね。
--encoding=sjis とか、nkf通す方法とかあるみたいだけどやってみた？
Windowsでちゃんと表示できてる人よろしくたのむ

部分ごとに変換したのを結合してページャに渡すなんて面倒くさいことしてないと思うから、
コミットメッセージの文字コードと管理しているファイルの文字コードが合わない場合は無理だと思うけど。

>>150
あ、log -p か。それは、>>154の言う通りかも。
ログ部分と差分のエンコーディングを合わせる何かを書いたらいけそうか

環境変数 git_pager
というのを変えればいいのかと思い
c:/tarou/xyzzy-0.2.2.235/xyzzy/xyzzycli.exe %1
としてみたらxyzzycli.exeで開かれはするのですが
%1というファイルを開いたことにしかなりませんでした。。。

git_pagerにたいしては%1みたいなのの変換(?)
とかはないんでしょうか?

>>156
%1いらないんじゃないの？

なしだと起動するだけで入力がありません...

xyzzycli ってエディタ？ ファイル名を指定しないと動かないってことかな。
git_pager にはページャ (標準入力を表示するもの) を指定する必要があるんじゃないかな。

ドザだけど log や diff は全部 gitk で見てるわ

>>158
Windowsだと何か違うのか…
git config --global core.pager /path/to/pager やら
GIT_PAGER=less git log やら $1 とかなしでいけるけど

>>159
emacsライクなWindows用のエディタだよ

>>156
ファイルじゃなくて標準入力で渡されるみたいだから
標準入力をを受け取れるエディタでないと無理じゃないかな。

http://www.forest.impress.co.jp/docs/news/20120323_520960.html
Bitbucketの次はまさかのCodePｌex

かなり無理やりですが
nkf -s > ./tmp.txt | start //wait /c/xyzzy/xyzzycli.exe -wait tmp.txt
として
tmp.txtへ出力しエディタで開き,
エディタ上で適宜文字コードを変えて読もうかと思ったのですが,
なんかtmp.txtが変です。。。

最初の文字列は
commit
のはずなのですが
.[33mcommit
と表示されます。なんかの制御文字か何かでしょうか？

commit
という文字列(git log -pで最初の行に書かれる文字列)の
前に出てる変なのをバイナリエディタで開くと
1B 5B 33 33 6D
となっています

リダイレクトもパイプも滅茶苦茶だよそれ

エスケープシーケンスでググれ

>>165
たぶん色の制御コード
git log --color=never -p
これで消えるんじゃないかな

Windowsって && とか ; とかシェルで使えないの?

>>170
&&は使える。; は、使えなかったような気がする

>>169
出来ました！
ありがとうございました

>>170
「;」は使えないが、かわりに「&」が使える。
ちなみに、「&&」「||」はそのまま使える。

CodePlex、Gitサポートを開始
http://sourceforge.jp/magazine/12/03/26/0529214

>>174
>>164

質問ですorz：
現在WinCVSを使ってまして、今度gitしたいのです。
SVNだと、RapidSVNとかありますが、
gitのFreewareクライアントGUIは何がありますでしょうか？

SmartGitは商用ではフリーじゃないそうですし、Tortoiseはどうもキモくて。。。

キモいのしかないので、CVSを使い続けてください。

>>176
Windows用ってことだよね

Ubuntu向けの記事だけど
http://gihyo.jp/admin/serial/01/ubuntu-recipe/0212
ここで紹介されてるgit-gui/gitkはWindows(msysGit)でも入ってる
あと使ってみたことはないけどQtベースのやつもWin版はあるっぽい

つ �d

記事を読んでみてあらためて気付いたのですが、
つまりGit GUIっていうのが標準で付いてるんですね。
リポジトリの作成ツールかと思ったら、リポジトリを開くとWinCVSみたいな画面。
それで、”既存リポジトリを複製する”をしてから、それ使うのがGit流、みたいな？
みんなこれでやってるのかなぁ？

gitkはブランチエクスプローラみたいなもんで、gitk上でブランチやコミットを操作することはないよ（何やってるかわからなさ過ぎるから）
いわゆるGUIオペレーションをしたいのなら、そういうのはフリーではないんじゃないかな

てことは、みなさん、Git GUI？

それともbashって、いつの時代だ（ｗ

>それともbashって、いつの時代だ（ｗ
>それともbashって、いつの時代だ（ｗ
>それともbashって、いつの時代だ（ｗ

bash地獄で悶えて市ね

たしかにbashっていつの時代って感じだよね
時代はzshだ

>>181
> それともbashって、いつの時代だ（ｗ

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　 ﾉノ　 ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　 　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll"ﾝ　　　 ´　　　i| l|||l"l　｀|: /|: : /'!/l 　 　 ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　 ､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　 う　 ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　"　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　 ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r"^~´"''''"t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お ・
　　　　　　　,;'~　　_r-- ､__　　　　　~f､_>'､_　　　　　　　　 |　　で　　前 ・
　　　　　　f~　　,;"　　　　　~"t___　　　　ﾐ､ ^'t　 　 　 　 　|　　は　　ん ・
　　　　　 ,"　　,~　　　　　　　　　ヾ~'-､__　ﾐ_ξ丶　　　　　|　　な　　中 ・
　　　　　;'　　,ｲ　.. 　　　　　　　　　ヽ_　　 ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　 （　;":: |:　:: ..　　　　　　　　　 .｀,　　 ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　 　　　l｀ｰ-､　　 ）l　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

Windowsでのbashは流行らない
いっときの間違ったcygwinの持ち上げられかたを見るとよくわかる

というか、CVSとSVNからの場合はGUIオペレータはなにも助けてくれないと思う
自前で覚えなければならないことが多過ぎる

ユーザーの追加もbashでやるのでしょうか？＿？

シームレスにスムースに移行できるようになりませんかとは言われるんだけど、根本的な概念が別個だからねえ

大昔のJavaBeansプログラミングみたいに、コンポーネントGUI操作だけでgitを使うことはできなくもないのかもしれないけど、
操作体系をうまく発明した人はまだいない

シームレスじゃないかわりに、ローカルで更新できるってのが、おもしろいですよね。
サーバーを外に持ち出すみたいな感じで不思議。

ま、外では会社のソースのコーディングなんて全くもってしないわけですが（ｒｙ

>>190
おそらくあなたに向けて話してるのではないと思う

みなさん、顔が見えてるわけですか（爆

>>176
> gitのFreewareクライアントGUIは何がありますでしょうか？
> SmartGitは商用ではフリーじゃないそうですし、Tortoiseはどうもキモくて。。。

bzrexplorer

bzr-git で快適 github 生活
http://d.hatena.ne.jp/methane/20111224/1324698755

TortoiseGitはあの不安定ささえ無ければ良いツールなのに

VM 内に Linux インストールして git 使うべきでしょう。

>>185
ゆのっちはMercurialでGitは宮子なイメージ

git恐怖症であれ以来触れません

>>182
今はdashだよな

子宮

つ �d

＞bzrexplorer bzr-git で快適 github 生活
etc.

>>192
尻尾は見えてるよ

普段何ヶ月も見たことのないような傾向のレスが特定の質問書き込み後に急にたくさん出るようになれば、そりゃあ、ねえ

Git GUIで、
・新しいリポジトリを作る
・既存リポジトリを複製する
を行いました。

「複写に失敗しました。 git リポジトリではありません」エラーになりますが、何ででしょう？
基本機能を２つ使っただけなのにぃ。

たぶん空のリポジトリを複製しようとしてるからだと思う

あ、やっぱそうですか。
そう思ってファイル１個追加したのですが、
エラーは消えないです。

メッセージを空欄にしてたため、コミット完了せずステージングにとどまっていました。
きっちり１ファイルコミットしたところ、エラーが消えました。
orz

ドンマイ

Windowsのファイル共有で公開したリポジトリをマスターにしたいのですが、
プッシュでエラー出ました。
ちょっと強引杉ますか？

＞Pushing to //Server-temp/GitMaster
＞remote: error: refusing to update checked out branch: refs/heads/master[K

自分がなにをしているのかわからないのであれば、それはするべきではない

・共有リポジトリは--sharedオプションつけて作った？
・他人がpushしてるんじゃないの。pullしてみたらどう？

逆にGitのWebServerを建てるのは簡単でしょうか？

かつ、GitサーバーとViualSVN Serverを同居させたかったり、という事情も。
ViualSVN Serverは起動中ですが、これはやっぱり実態はWebServerですよね？

そうなると、WebServer同士でHTTPアクセスの取り合いで片方あぼーんでしょうか。

連続質問すみません。分からないことだらけなんです。

ﾚｽ�d。

＞・共有リポジトリは--sharedオプションつけて作った？
Git GUIで作りましたので、オプション設定場面はありませんでした。

＞・他人がpushしてるんじゃないの。pullしてみたらどう？
まだ一人でテスト中なので他人はアクセスしていません。
でも、pullテストはしてみます。
でも、今回の解決にはならないとは思っています。

連投すみません、一時的な連投です。

＞pullしてみたらどう？
Git GUIには、プッシュはあっても、プルがないことないですか！！！
そんなはず無いですよね？？？

＞pullしてみたらどう？

「リモート」−「から取り込む」メニューですよね？
これは実行できました。

しかし、プッシュエラーは消えません（＞＜）

>>209でFA
「なにも知らない」人がなにも知らないまま使えるようにはなっていない
内部発行コマンドが見える程度の知識は絶対に必要
初心者が楽に学習するためのアプリケーションではなく経験者が概観するためのアプリケーション

つまり209=215は、初心者に話しかけるなでFOすると。

GUIだから初心者でも簡単に使えるはずという信仰は根強いな
シーケンシャルに辿れるぶん、コマンドラインのほうが簡単なことも多いと思うんだが

昼からまったく進んでないようだが、コマンドラインなら5行くらいで終わる内容に見える

つかわざわざ自分から操作難しいほう選んでるんだからGUIに文句言うな

>>208
「refusing to update checked out branch」でググれば対処方法は出てくる
だがgit guiから出来るかは不明なのでgit bashからやった方が楽だと思う

GUI縛りっていう一種のプレイとみた

　 　　　∧＿∧
　　　　（ ・ω・ ）　　
　　 　 （=====）　　
　　 __ (⌒(⌒ )
　／＼￣￣し'￣￣￣＼
　￣￣￣￣| |￣￣￣￣
　　 　 　 　 | |
　　 　 　 ／　＼　

一度 push した後で amend したとかじゃねーの？

しかしpushもamendも知らないんだよねこの人

うちの会社もあと100億あったら何とかなる気がする

GUI だからといって git としての理解と動作は特に助けてくれないからなあ
git を学んでから補助として GUI 使うのがいちばんマトモな利用法だと思う
あと日本語入力が通らないことが余裕であるので注意

gitg 使ってるんだけど、コミットの差分を表示したあと、
「実際はこの前後どうなってるんだろう？」と思ってもその差分があるファイルの部分に直接飛ぶことができないので困ってる
これができるリポジトリブラウザってある？
ファイルツリー表示はあるんだけど、ここは検索ができないので目視で探すしかないという変態仕様

Windows版もUTF-8対応してくれたのでうれしい
もう文字化けに悩まされなくなったし
不安定ってこともない

ちなみに >>223 をやったら何が発生するのでしょうか？

1. commit && push
2. commit --amend
3. もっかいpush
4. remote「Already up-to-date」
で、リモートはamendできないみたいな流れ？

いえ、そんな複雑な話でなくて一度目でエラーです。
リポジトリのコピーは作れども、一度もpushできず、みたいな（＞＜）

bashからやってみれば？

作りたてのベアリポジトリにブランチ指定しないでpushしたんじゃないか？

　git remote add //Server-temp/GitMaster
　git push -u origin master:master

これでどうよ。
後は git push と git pull でいけるはずだが。

あとリポジトリ名には .git がついてないと気持ち悪いな（//Server-temp/GitMaster.git）。

>>232
訂正。

　×　git remote add //Server-temp/GitMaster
　○　git remote add origin //Server-temp/GitMaster

git initもcloneもgit guiで作業してたみたいだから
たぶんどのリポジトリもベアリポジトリになってないんじゃないかな
だからカレントのブランチ(master)に対してのpushが制限されてるんだと思う

これについてはpush先のリポジトリに対して
$ git config --add receive.denyCurrentBranch ignore
で回避できると思うけど
まぁ共有するリポジトリは--bare付きで作りなおしたほうがいいのかな

githubで
git remote add origin [email protected]:foo/hoge.git
git push -u origin master
としても
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
とでます,どうすればいいんでしょう?

>>235
＞Permission denied (publickey).
これだろ

それをどう解決するんでしょうか?

>>237
それ、自分のリポジトリ?
github に SSH public key が登録されとらんのじゃないの？

すみません.解決しました↓

>>239
結局なんだった？

インド人を右へ

>>235
馬鹿には無理

>>226
gitkで差分表示を右クリックして「この行にgit guiでblameをかける」か
ファイル名を右クリックして「外部diffツール」

blameの方は右クリックした行によって表示されるファイルのリビジョンがかわるから
（たぶん選択してるコミットのファイルが見たいんだよね）
ファイルが表示されるときに特定の行へ移動させることにこだわらないなら
外部diffツールの方がいいのかな

>>232 作りたてのベアリポジトリにブランチ指定しないでpushしたんじゃないか？
>>234 たぶんどのリポジトリもベアリポジトリになってないんじゃないかな

Gitには今まで無かった概念が入ってるんですね。
とりあえずベアリポジトリの勉強をしてみます。その次にやることはbashでリポジトリの再作成でしょうか。

その引用の仕方は紛らわしいわ

＞ttp://progit.org/book/ja/ch4-2.html
＞Git サーバーを立ち上げるには、
＞既存のリポジトリをエクスポートして新たなベアリポジトリ
＞(作業ディレクトリを持たないリポジトリ) を作らなければなりません。

ということは、Git GUI で、リポジトリを作成しただけではダメということですか？

Windows 用の Git クライアントは Git Extensions がおすすめ
http://sourceforge.net/projects/gitextensions/
--bare --shared なリポジトリも作れる

もっとも、最初は bash で使い方を覚えたほうがいいとは思うけどね

TortoiseGitの新バージョン来てるよ

TortoiseGit-1.7.8.0-64bit.msi - tortoisegit - TortoiseGit-1.7.8.0-64bit - Porting TortoiseSVN to TortoiseGIT - Google Project Hosting
http://code.google.com/p/tortoisegit/downloads/detail?name=TortoiseGit-1.7.8.0-64bit.msi

32bit貼ってなかった

TortoiseGit-1.7.8.0-32bit.msi - tortoisegit - TortoiseGit-1.7.8.0-32bit - Porting TortoiseSVN to TortoiseGIT - Google Project Hosting
http://code.google.com/p/tortoisegit/downloads/detail?name=TortoiseGit-1.7.8.0-32bit.msi&can=2&q=

カメなんて使ってる奴いるの？

ﾉｼ

Gitを勉強しようと思うのだけど、Windowsだと何を使ったらいいですか?
msysGit というのが最近 UTF-8 対応になって幸せ、というのをどこかで読みました。
ただし subversion のときも、コマンドラインを学んでからTortoiseSVN に手を出しましたが、
WindowsにVMware で Linux 入れて、そっちのコマンドラインで学んだほうがいいでしょうか?
(自分は Linux も日常で使っているので、別にそれでも構わない)

Git の windows版コマンドラインを使うのなら、msysGit 内蔵の Git Bash を
使えばいいのですか?

TortoiseGitってどうせ日本語対応Gitじゃあんまりまともに動かないんでしょう？（・ω・,）

>>252
>(自分は Linux も日常で使っているので、別にそれでも構わない)
だったらlinux使えばいいじゃね？

>>254
あ、自分一人だったらそれでいいのですが、
職場のチームにも広められれば、と思っていて、Windowsで完結できればそれが嬉しいので…

Git Extensionて、選択多いですね。
MsysGit/KDiff3の選択は、MsysGitで良いとして、
OpenSSHのGit defaultじゃなくてPuTTYが選択されてるけど、無問題なのかなぁ。

Gitって、サーバーとクライアントがSSHでつながってんだね。SSHって使ったことないけど。
TTYってWindowsで動作するんだろうか。

すみません、初歩的な質問ですが、
WindowsサーバーでMsysGitだけではC/Sで動作しなくて、
Git Extensionを入れるとSSHかTTYでC/Sとなる、
という理解であってますでしょうか？

>>257
Git Extensionsはクライアント側のGUIですよ
MSysGitだけでサーバ構築できるかはよくわからない、ごめんなさい

あってねえよ
Git Extensionは単なるＧＵＩだ

全然違う！
Git ExtensionはただのGUI
ぜんっぜんっ！違う！！

了解です。
GitのC/Sは何でつながって、何をインストールすればよいのでしょう？
上のSSHやTTYであってますか？

ちなみに知りたいことは、
GitをC/Sで使いたい、サーバーはWin、認証までは要らないので、HTTPサーバーレス希望です。

今のところはcygwinでやるしかないんじゃないか？
>>256には無理そうだからhgにすれば…

漢ならrsync

おしゃれな私はDropbox

>>263
認証無しのノーガードでもいいならmsysgitでもgit-daemonが使えた

サーバー上のd:\reposに置いてあるリポジトリをgitプロトコルで全て公開し
認証なしでpushも出来るようにする場合
サーバーにmsysgitを入れて以下のようにする
$ git daemon --base-path=/d/repos --export-all --enable=receive-pack

とは言ってみたものの、さっきちょっと試してみたら
クライアントがmsysgitだとpushが途中で固まった(linuxからだと正常終了する)
うちの環境が悪いのかもしれんけど
実際に使うとなったら試行錯誤が必要かもね

Git Extensionsのリポジトリ作成を行ったところ、
＞共有リポジトリは--sharedオプション
できました。

そうしたところ、>>208 のエラーは消え、プッシュできました。

しかしプッシュで使ったのとは別のリポジトリ複製からチェックアウトしても、
プッシュした内容が反映されません。
どういうことなのでしょうか？＿？

ちなみに昨日入門GiT古本を買いました。

さらに、マスターのリポジトリからリポジトリ複製しましたが、
やはりプッシュした内容が入っていません。
明後日の方向（古）にプッシュしたのでしょうか？

>>267
checkoutじゃなくてpullじゃね？
pushした内容が入ってないってどうやって確認したの？

あ、checkoutはローカルのリポジトリ内の処理ですか。
リモートのリポジトリのpullは、、、「から取り込む」メニューをGit GUIで実行しました。
しかし、落ちてこないです？＿？

＞pushした内容が入ってないってどうやって確認したの？
マスターのリポジトリから、リポジトリ複製して確認しました。

つまり「checkout <---> pull」を間違っていただけじゃなくて、
pushにも間違いがありそうです（＞＜）

あれ？
Git Extensions でリポジトリ複製したところ、ちゃんとpullした内容が落ちてきたぞ？
もしかして、Git GUI が落とし穴なだけ？＿？

PushのダイアログのブランチのPushの
＞Pushするブランチ「」から「」
の意味がわかりませんorz

分からずに両方とも"master"って入れています。

でも普通にアップする場合って、最新としてアップするので、
自分的イメージではHEADを選択なんだけどな。
でも、HEADってのも最新て意味でなくて、ただのブランチ名だろうか。

分からないことだらけOTL

連投すみません。

ブランチって、CVSでいうブランチですね。頭の中でrevisionとゴッチャになってた。
ブランチってことなら >>272 のダイアログの意味がわかりました。

それは納得として、適当に使ってたら、勝手にブランチが作られた希ガスる。
何が起こったんだろう。。。

HEADは現在のブランチを指す
masterはリポジトリ作成時にデフォルトで作られるブランチ名

入門Git買ったならとりあえず全部読むと幸せになれるよ

>>270
>リモートのリポジトリのpullは、、、「から取り込む」メニューをGit GUIで実行しました。
メニューの「リモート」にある項目のこと言ってるのなら
「から取り込む」じゃなくて「から刈込む」だと思うのだが

git guiでpullするなら
メニューの「リモート」「取得元」「origin」をやってから「マージ」「ローカル・マージ」

これ全部読め。

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

いきなり環境から作ろうとせずにgithubとかbitbucketとかでクライアント
での利用(練習)から始めりゃいいのに。

Git GUI とそれで作った（と思い込んでいるもの）は全部捨てろ
理解できなければもう一度だけ繰り返す、Git GUI は全部捨てろ

素直にcuiでやった方が覚えが早いと思うよ

覚えが早いというかGUIは別にわかりやすくも使いやすくもないことが理解できるだろう。
まあもうちょいコマンド体系が整理されてくれたらと思うが。

ドキュメント読まないヤツは相手にするなよ

おま、ボッチだろｗ

馬鹿には無理

＞あとリポジトリ名には .git がついてないと気持ち悪いな（//Server-temp/GitMaster.git）。

.gitって付けるもんなんだ。

cvsはフォルダ名には付けない風な気がするけど、どうだったかなぁ。
後、svnはどうなんだろう？

Git Extension でCommit＆Pushしようとすると、
ブランチができますって出ます。

ブランチ作りたくない場合はどうするのでしょうか？

Git GUIで作ったものは全て捨てました。
リポジトリは--bare付きで作りなおしました。

この次のCommitやPushは、Git ExtensionよりGit GUIの方がメニュー的な気がしますが、どうなんでしょう？
やっぱり、Git GUI＝アクでしょうか。

Git GUIで、「既存のリポジトリを複製する」を行いました。

＞fatal: Couldn't find remote ref HEAD
＞fatal: The remote end hung up unexpectedly

というエラーなんですが、何ででしょう？

HEADがないから

頭が足りないのか

GUIの人はいい加減お帰りください。

CVS使ってる時は、Winユーザーが勝手にユーザー名になりました。
SVNでは、VisualSVNでユーザーを追加しました。
Gitではどうなりまつか？

試して報告しろ。

変更したファイルを赤色表示で見るには、どうすれば良いのでしょう？

git-completion.bash を読み込む

>>291
github使ってみ

>>228
同僚から蛇蝎の如く疎まれ、蔑まれ、罵倒される。

>>262
設定面倒でコミッタ少ないなら共有ファイルサーバでいいんじゃない？

>>284
bareリポジトリには慣例的に.gitをつける。
同僚から文句出ないなら好きにすればいいよ。

リポジトリ名に.gitを付けるのはベアリポジトリの場合の慣習。

あるコミットのIDを指定して、それをdiff形式 (patch形式?) で取り出すのってどうやるんですか。
git log -p COMMIT-ID
で見れることは見れるんですが、親のコミットも表示されちゃうし、もっといい方法はないでしょうか。

git diff commit-a commit-b
でaからbまでのdiffとれるでしょ

git show COMMIT-ID とか、
余分なdiff以外の部分を出力したくないなら git diff COMMIT-ID^ COMMIT-ID とか？

>>298
$ git show COMMIT-ID > foo.patch
$ patch -p1 < foo.patch
もしくは
$ git show --no-prefix COMMIT-ID > bar.patch
$ patch -p0 < bar.patch

相手もgit使ってるなら素直に
$ git format-patch -1 COMMIT-ID
したほうがgit-am使えて便利。

$ git clone repo.git
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/feature1
remotes/origin/feature2
remotes/master

あるリポジトリからcloneした直後は上のような状態になっていますが、
master以外のbranchをローカルに復元したい場合は
$ git checkout -b feature1 remotes/origin/feature1
$ git checkout -b feature1 remotes/origin/feature2
のようにするしか方法は無いのでしょうか？

この方法だとタイプミスとかあっても気付かないし、何より面倒くさいですよね。

正しい方法か知らんけど
cp .git/refs/remotes/origin/* .git/refs/heads/
とか

git checkout -t origin/feature1

remotes/origin/feature1をorigin/feature1に省略可能なのはいいとして、
git checkout -t -b feature1 origin/feature1
git checkout -b feature1 origin/feature1
git checkout -t origin/feature1
これ全部同じか。
cp .git/refs/remotes/origin/feature1 .git/refs/heads/feature1を
してくれるだけじゃなくて、.git/configにこの三行追加してくれるんだな。
[branch "feature1"]
remote = origin
merge = refs/heads/feature1

リモートのブランチを全部ローカル上に作っても、
リモートの変更をローカルのブランチに取り込むためには、
各々checkoutしてpullしないといけないから、
あんまり現実的な使い方じゃないよね？

$ git checkout feature1
$ git checkout feature2
でもよかったりする

>>307
それ detached head になっちゃわない？

git checkout feature1 でいけるな。
git checkout origin/feature1 だと detached HEAD になるね。

indexを変更せずに、あるコミットからあるファイルをworking treeに取り出すにはどうしたらよいですか？
checkoutもresetもpath指定できますがindexを変更してしまうようです

>>310
取り出した後に何かするんじゃないの？
見るだけなら
git show branch:filepath
取り出したいのならリダイレクトすればいい
git show branch:filepath > filepath~

特定コミット時点でのファイルの状態を
index=HEADの状態のままworking treeに持って来たいとき、
git commit コミットID ファイル名; git reset ファイル名
とかやってたが、>>311のやりかたで上書きすればいいのか。
git show はいろいろ便利だなあ。

おう
そうよ

>>312
diffの連続を効果的に管理するのがバージョン管理だから、上書きするのはほぼ最終手段ね。
git diff branchA branchB -- filepath
とかで確認とったり、きちんとcherry-pickやrebase使わないと日付バックアップと何も変わらない。デグレードの危険。

公開してるブランチの特定のファイルを少し前の状態に戻したいときは、
git show commit-id:filepath > filepath; git commit -a もしくは、
git checkout commit-id filepath; git commitすればいいよね？
(上記2つは同じ状態になるよね？)

別のブランチをつくってそこでrebaseで戻してそれをmergeするとかを
つねにやったほうがいいのかねえ。

>>315
公開してるならマズい。誰かが今そのブランチを元に作業してるかもしれない。
上書きしてしまうとマージする時に混乱するから素直にrevert使って、
git revert commit-id

直そうとしてるコミットが行儀悪くて他の変更も一緒くたにしてしまってる場合はかなりややこしい。試して無いけどこんなかんじ：

git checkout -b fix
git revert commit-id
git reset HEAD^
git add -p
git commit -m 'commit-idから一部だけrevert'
git checkout -f
git checkout master
git merge fix
git branch -d fix

問題の無いコミットから今のコミットまでに別の変更が紛れてても分かるようにするのがいいと思う。

>>315
>(上記2つは同じ状態になるよね？)
同じになるかどうかだけで言うと
リダイレクトではファイルへ書き出すだけで属性(mode)とかは操作しないので
そのcommit-idの後にファイルの属性を変更していたら同じにはならないと思う
まぁあまりないとは思うけど

>>316
revertでコミットを無効にするコミットを作るのと、
自分でコミットを無効にするコミットをcommitするのとは、
コミットメッセージのデフォルトにrevert関連の情報をいれてくれることと、
reflogに記録が残る(これは時間がたつと消えるのかな)以外に何か違いはあるのかな？
そのあとのmergeとかの動作に影響があるのだろうか。
まあでも、打ち消したコミットのIDがメッセージに残るのは重要だと思うので、
これからはrevertを使うおう。

後半の9行が何をやってるのかは、ちょっとよく考えてみる。

あと、ためしにrebaseで特定コミットを削除したブランチをmergeってやってみたが、
rebaseしてないほうのブランチにコミットが存在することが優先されて、
mergeの結果そのコミットは存在することになるんだな。よく考えれば当然か。
正式な環境でこんなことやったら大顰蹙だったよ。気が付いてよかった。

>>318
昔のコミットで上書きしたらそれまでのコミットが全部無うなってまうがな。
revertはリバースパッチだからそれまでのコミットが生きる。
「間にコミットなんかねーよ」って思い込み運用してたらそのうち痛い目見るよ。

公開したコミットをamend,reset,rebaseとかで修正してpushしようとしたら
怒られるでしょう？
--forceつけるとコミットを削除してpush出来る、と言うようなメッセージが出るけど
GitHubとかでやっても出来なかった
Mercurialの場合は強制的にpushするとマルチヘッドになっちゃうらしい

>>320
おおう。確かにそうだね。
まあ、上書きcommit前にHEADとdiffして意図しないものが含まれてないか
どうかはチェックしてるから大丈夫そうだが、一歩間違えば大惨事だ。

>>314
diffで管理しないのがgitの特徴の一つじゃなかったか

>>321
それはたぶん、相手がfast-forwardでないpushを絶対受けつけない設定になってるから。
ローカルでfast-forwardな状態になるようにmergeなりrabaseなりをしてからpushしないと。
>>319はpushの前のmergeが意図したものになってなかったっていう話。

>>323
コミットが、修正前のコミットへのリンクと現時点でのファイルの本体をもってるなら、
コミットはdiffと同等な情報を保持してるってことでいいんじゃないのかね。

git-svnでSubversionのリポジトリをcloneすることで
Gitを使い始めたのですが、
マージコミットとgit svn dcommitについて教えていただけないでしょうか?

(1) Gitでブランチを作って作業して、
(2) それをgit merge <ブランチ>でmasterにマージしてから、
(3) git svn dcommitしようとしたときにわからなくなりました。

(2)でマージしたときにfast-forwardにならなかったら
「どこそこブランチをマージ」というログだけのコミットができていました。
（↑これのことを"マージコミット"と言っていますが、合っていますか?）
この状態でこのままgit svn dcommitした場合、
Subversion側ではどういう扱いになるのでしょうか?

単純に時系列順にSubversion側にコミットされていくだけで、
特に意味は発生しないのでしょうか?
そうであれば、git svn dcommitするのは
マージコミットがない状態にしてからのほうがよいでしょうか?

cherryというコマンドの、名前の由来を教えてほしい。

alcでは：
cherry
【名】
サクランボ（色）、サクラの木
〈米俗〉新品、初心者
〈米俗〉良いもの［こと］、格好いいもの、いかすもの
〈性俗〉処女、処女膜、童貞◆下品な俗語

git-cherryのマニュアル：

git-cherry - Find commits not merged upstream

The changeset (or "diff") of each commit between the fork-point and <head> is compared against each commit between the fork-point and <upstream>. The commits are compared with their patch id, obtained from the git patch-id program.

どう関係するのかさっぱりわからない。

>>327
cherry picker はクレーン式高所作業車で、git cherry-pick は枝にぶらさがってる特定のコミットを（作業車に乗ってる人が）別の枝へ移動させるイメージ
これから分岐したのが git cherry というコマンド
git cherry が先にあったわけではない

cherry pick で「つまみ食い」

>>328-329
cherryというもとの単語には意味はなく、cherry-pickの対象だからcherryとしただけか。なるほど。
さんくす。

>>326
＞「どこそこブランチをマージ」というログだけのコミットができていました。
＞（↑これのことを"マージコミット"と言っていますが、合っていますか?）

どちらもコミットオブジェクトであると言う点で、マージと通常のコミットはそんなに差のあるものではないんだが、まぁ合ってるっちゃ合ってる。

＞この状態でこのままgit svn dcommitした場合、
＞Subversion側ではどういう扱いになるのでしょうか?

>>326が言うところの「マージコミット」に含まれる変更がコミットされた、という扱いになる。

＞そうであれば、git svn dcommitするのは
＞マージコミットがない状態にしてからのほうがよいでしょうか?

その通り。git-svnを使う場合はmergeじゃなくrebaseを使った方がいい。それほど詳しい内容じゃないが、だいたいの理由は↓に書いてある。

http://progit.org/book/ja/ch8-1.html

レスありがとうございます。
教えていただいた先も読んで、
考えてみます。

tig使ってる人っている？

リモートのbareリポジトリに誤ってブランチをpushしてしまいました。
このリモートにあるブランチを消したいのですがどうすればいいですか?

>>334
http://progit.org/book/ja/ch3-5.html

>>335
ありがとうございますー
こんなやり方だと忘れそうですww

今日はじめてgitを触ったんだけど、皆もBashにカタカタ打ち込んでバージョン管理してるの？
CUIに慣れれば簡単にバージョン管理できるようになるんだよな？な？

>>337
あなた次第です。

>>338
じゃあ無理だわ。

>>337
何いってんだよ・・・そんなわけ無いじゃん！

>>339
戦う前から負けることを考える奴があるか

かれこれ1年使っているが、未だにgitをメインに出来ないでいる

1年前の俺に「素直にsubversionにしとけ」と伝えたい

もう、subversionには戻れないけどなぁ〜

もうsubversionの使い方とか覚えてないわー

hg使っとけ

ぎっとぎとにしてやんよ

何度git使ったけど、その度にsvnに戻ってる。

馬鹿には無理

それは本当にそう思うわ
俺には使いこなすの無理っぽい

BSD界隈の人は「CVSで十分」とか言ってる始末

嘘は良くないな

openbsdは未だにcsvでやってるな。
ライセンスが気に入らなくて自前で再実装までしたはず。

じゃなくてcvs

>>351
ほんとだって！
ttp://twilog.org/AoiMoe

PostgreSQLもまだCVSじゃなかったっけ？

ProGit読んでダメって奴は正直バカには無理とかそういうの以前に人間としての知能を疑われるレベル

BSD勢はライセンスが気に入らないってのもあるかも。

>>357
OpenBSDとかそのせいでgzip(.gz)廃止して一昔前のcompress(.Z)使ってるしな

ライセンスが気にくわないならそう言うべきで、それを「CVSで十分」って
言い換えるのは「あのぶどうはすっぱい」そのものなんじゃないかと。

しょっぱいお兄ちゃんかあ
言うこと極端だからね

git最高他はゴミ。

しょっぱいデザート？

もしかしてシャローコピーじゃチマチマアップデートを受けとる使い方ってできない？
しかもシャローコピーをしたディレクトリにシャローコピーの上書きなんてこともできない？

AoiMoeの人には、しお兄ちゃんという呼び名があってだな。

まだ会社辞めてないの?

これチェックアウトしたファイルはワーキングディレクトリ以下にしか散らばらないということでいい？

勝手にはみ出てきたら怒りより笑いがきそう。

Windows 環境でシンボリックをコミットするにはどうすればいい？

>>366
いや、svnならワーキングディレクトリはホームのまま
svn用のディレクトリへチェックアウトして
さらに別のディレクトリへワーキングコピーを作って
みたいにできたじゃん？

>>368
svnのチェックアウトというとgit cloneに近くないか？

"A successful Git branching model"の運用を採用しようと思ったのですが疑問があります。
現在の製品の安定バージョンが3.2として、3.2.1、及び3.2.2（導入未定）を開発してるとします。この場合、各ブランチは

- master: 常に安定版が置かれる。この場合は3.2のソースがrelease-3.2ブランチからマージされた状態
- develop: 3.2.1を開発
- feature-3.2.2: 3.2.2を開発

となるのでしょうか。
また、3.0や3.1でブランチを分けたい場合、名前はどうするのがベターでしょうか。
release-* はこのモデルの場合、一時ブランチに使用する名前みたいなので、3.0-stableとかにするべきなのでしょうか。

sage

小便してたらうんこが漏れた

githubの質問なんだが、プッシュした時のコミットログのユーザ名が、ローカルで設定したものと違う自分と接点のないユーザ名になる
別環境のローカルにプルしてgit log 見るとちゃんと元々設定したユーザ名が表示される
新規作成したリポジトリでやっても同じ結果…
似たような現象になった人いる？
素直にサポートにメールした方がいいだろうか

メールアドレス間違ってんだろ

ｻﾝｸｽ
githubのコミットユーザ名ってメールアドレス依存なんだな…微妙な仕様

同姓同名がいるのは当然なんだから
URI であるメールアドレスで一意性を確保するのは当然だろう

ブランチしてマージしてちゃんと動くの、これ？

ちゃんと動くかどうか担保するのはテストだ
gitを含めVCSは管理を提供するに過ぎないよ

2系統で進化した2つのソースをきちんと混ぜることができるのか、という話なら、
7割くらいは自動で（私たちが目で見て普通に考える以上に）論理的にきちんとマージされる

残り3割は「こことここがカチ合ってると思うのでエディタで手動で混ぜてねごめんこ」というテキストファイルになる

merge より rebase のほうがすっきりして好き

意味が分からん
rebaseでもmergeしてるだろ

マージコミットが邪魔という意見かなとエスパーのふりをして答えてみる

他ブランチの変更を自ブランチに取り込む方法として
mergeを使うかrebaseを使うかって意味なら、
別に>>380は何もおかしくない。

ていうかそういう話だろ
実際に衝突しかねない他人のブランチを取り込む手段としてはrebaseのほうが人気
あんまり衝突しそうにない自分のブランチならmerge

今日になっていきなり、以下の様なメッセージが出てきました

Your branch is ahead of 'origin/master' by 13 commits.

これは何を表しているのでしょうか？また、どうすれば良いのでしょうか？

どうすれば良いかはおまえさんにしかわからん

症状としてはそのメッセージのまんま
別に気にしなくてもいい

ローカルとリモートのブランチの対応付けとかがデフォルトのままなら

リモートのmasterブランチの修正が、リモート追跡ブランチorigin/masterに取り込まれてる。
でも、それがmasterブランチに取り込まれていない。

git fetchやったか、別のブランチをcheckoutしてる状態でgit pull originやったとかの、
結果だと思われる。

masterブランチをcheckoutした場合にそのメッセージが出てるんだと思うんで、
修正をmasterに取り込む必要があるなら、そのままgit pull originとかやればいいと思う。
masterブランチ放置ならそのままでも。

>>386-387
どうすればこのメッセージを消せますか？

>>388
git pull origin しても、"Already up-to-date."と表示されます。
ブランチも master しかありません。

実際どうなのよ？そのoriginのmasterは、自分のmasterに取り込まれてるの？

>>390
何も考えずにgit pull originしちゃったみたいだけど、originの修正を取り込んで良いの？
どっかからcloneしてきたmasterブランチを自ら修正してるんだよね？

>>391
すみません、git使いはじめてまだ1月くらいしか経ってない未熟者なので、質問の意味が理解できません。
申し訳ございません。

>>392
clone元も自分のローカルディスクにあります。

>>393
何も考えずにgit pull originしちゃったみたいだけど、
clone元側の修正を取り込むつもりなのか？そのつもりはないのか？

うんこしたらすっきりした

>>394
修正を取り込むつもりはありません。



大変申し訳ございませんが、質問を取り下げさせていただきます。
glt clone の使い方を間違えていたみたいです。
ただ、元のディレクトリのコピーを作成するだけだと思っていたのですが、どうやら関連があるようですね。

もっとgitの勉強してきます。

皆様、ありがとうございました、そしてスレ汚し大変失礼いたしました。

なぜそう思ったんだろう。

>>396
レポジトリのコピーする目的でgit cloneするのは別に間違って無い
>>385が出てるのは必要も無いのにgit fetch系の操作をしたんだろ
clone元との関連を完全に断ちたいなら、それなりの操作が必要

>>385って、remote tracking branchをcheckoutしたときに
（リモートブランチから後に）13コミットもされているから、そろそろpushしたら？とお勧めしているんだろ
trackオプション無しで作ったブランチだと出ないと思う
pushする気無いならそっちで

オープンソースのスパゲッティに自作そうめんを混ぜ込みたい訳でもないのに
それが可能なまるごとコピーがあたりまえというのがうんこ。

git cloneする
リモート追跡ブランチのmasterが自動的に作成、チェックアウトされる
↓
masterに13個コミット
↓
masterをチェックアウト
Your branch is ahead of 'origin/master' by 13 commits.
？？？
↓
git pull origin
origin/masterは最新なので何も起こらず

clone元で何か変更があったとしても
fetchで取得された最新コミットとマージされるだけじゃん
>>385のメッセージは消えないだろう　別に消す必要もないと思うが

チェックアウトしなおうすときるえ

git addした以降のワーキングツリーの変更だけを取り消すにはどうすればいいんでしょう？
http://d.hatena.ne.jp/murank/20110327/1301224770
に記載されている図で、ワーキングツリーが指している場所を
インデックスが指している場所に戻すイメージなんですが…

今は一旦commitした後reset --hard, reset --soft HEAD^ ってやってるんですが
もう少しシンプルに(commitせずに)できる気がして…

>>404
git checkout -- ファイルパス
かな？

>>405
即答ありがとうございます！
そうか、上のサイトやhelpにもありましたが、reset(の本質)はHEADを操作するためのコマンドで、
ワーキングツリーを操作するのは、本来はcheckoutなんですね。

慣れるまでなかなか難しいな。
日本語の良さげな資料はここから辿れる？

http://matome.naver.jp/m/odai/2133603706882852201

Pro Gitで基本知って、A successfulで運用学べばいいんじゃね

あと日本人が書いた本は使わない。
これ大事。

junioをdisってんの？

どうせ誰も使ってないTortoiseGit1.7.9.0で日本語ファイル名対応でっていう

>>411
後はTortoiseGit 1.7.9.0の日本語化パッチが出たら
ライトユーザーに気軽に勧められるようになりますね。

TortoiseGit Japan
http://tortoisegitjapan.com/

日本語化パッチを配布するのはいいんだけど、パッチファイルだけしか配布してない？
ソースコード何処？

導入の煩雑さが改善されないことには勧めにくい

>>413
https://twitter.com/#!/tgitjpn/status/191192379917733888

リソース書き換えていたのか
言語ファイル作るんじゃなくて？

>>412
前に亀水銀使ってたけど
cui触るまでなぜ分散が流行ってるのか理解できなかった
オレがバカなだけかもだけど

>>415
理解に苦しむ

>>417
分散のメリットは色々あるけど1つ言ってみる
ローカルにリポジトリが複製されるから、コミットやマージが速いでしょ？
十分テストしてからリポジトリを同期すればいいから、ミスを恐れながらコミットする必要がない

こまめにコミットできるのはいいよな。

コミットをやり直せるのもいい

「cui触るまで」だからもう解説いらないのでは

>>422 そうですね！

gui触ったことないけどどうなのよ
ワークツリーを適当に修正しまくった後に
必要なとこだけ何段階かに分けてインデックスに入れてコミットとか
こまめにコミットを繰り返したあと
リベースで必要なコミットだけを整理していくつかのコミットにまとめなおすとか
簡単にできんの？

こまめにコミットを繰り返し地獄で悶えて市ね

履歴を見たり、add -i相当の操作ぐらいまではGUIのほうがいいけど、それ以上は期待するな。
特にrebaseは絶対コマンドラインで確実にやるべき。

理屈で言えば、コミットの転写やブランチの移動なんてのは
「オブジェクト単位」で見せながら操作すると超やりやすくわかりやすくできそうなんだけどね

現実はうまくいかんもんだ
UMLエディタみたいなもんか

逆にGUIが使えない環境の場合に、gitk相当のことをcuiでやるにはどうするのがベストかな？

俺も履歴いじりに特化したGUIフロントエンドが
欲しいよ。
hunk単位でドラッグしたらコミット間で入れ替えられて、他のブランチまで考慮に入れて矛盾なくrebaseしてくれるようなやつ。

>>428
標準入力から受け取った内容をそのままテキストエディタで開くコマンドがあると何かと楽かも。
git logやgit diffの結果を開きっぱなしにしたまま次の操作ができるだけで違う。

tmux

cherry-pickのためにハッシュ値をコピペしたりするときちょっと寂しいのは確か
「これを…こうなんだけどなあ（手の動き）」みたいな感じ

馬鹿には無理

端末多重地獄で悶えて氏ね

>>424
> ワークツリーを適当に修正しまくった後に
> 必要なとこだけ何段階かに分けてインデックスに入れてコミットとか
git add -p か git commit -p

> こまめにコミットを繰り返したあと
> リベースで必要なコミットだけを整理していくつかのコミットにまとめなおすとか
> 簡単にできんの？
git rebase -i

TortoiseGitが言語ファイルを作ってもコンテキストメニューしか日本語にならないのは
多くの部分がハードコードされていたかららしい

>>434
たぶん、>>424は、それをTortoiseGitとかのGUIでやれるのか？って聞いてる。

最初からguiと明記されてるのにドヤ顔でコマンドを書いてる子

バスガスバクハツ

GUIの中に「コマンドを指定して実行」みたいに
CUIでの操作もできるようになってるといいんだけれどね。

なってるぞ

msysgit の gitk で UTF-8 の diff が化けずに表示されていたのが化けるようになってしまった
どこに設定ある？

git config gui.encoding UTF-8 で行けた

特定のファイルのある日から現在までの(加えられた変更の全ての)差分を取るにはどうしたらいいのでしょうか?
git log -p -after 2012-04-01 -- ファイル名
↑だと2012-04-01からコミット歴が分かるけど、コミット別に表示されてしまいます。
git diffでコミット指定してやればいいのかな?
日付の指定の仕方が分からないけど...

>>443
git diff <refname>@{<date>}..<refname>@{now} -- <path>
でどうかな
revisionの指定方法はgit-rev-parseのマニュアルに書いてあるよ

サーバにある複数の Git リポジトリのバックアップを rsync などのミラーリングツールで取ろうと思うのですが、誰かが push している最中に rsync が走った場合、コピーされたリポジトリが壊れていたりすることはあるのでしょうか？
一つ一つ clone した方が確実だとは思うのですが、私の知らない間にリポジトリが増えていたりもするので、できれば rsync などでリポジトリの親ディレクトリごとバックアップしてしまいたいのです。

それを2chで質問するのは意味がないのでは。
答が「はい」だとして、その答の確実性は担保しようがないでしょう。

>>445
親ディレクトリから1階層だけ find して git bundle するスクリプトを書けば良いんじゃないかな

クライアント側にもリポジトリ残るからバックアップしなくても大事にはならないんじゃない。
てか自分でサーバー構築しなくても、GitHubなどのサービス使ったらいいんじゃないの？

バックアップ中は git push を拒否すればいい

ディレクトリ内にあるすべてのリポジトリで
git push -allをするスクリプトを書く
リポジトリをまだバックアップ先に作っていなければclone
でどうだろう

git bundleは差分バックアップとして使えるの？
ネットワーク繋がっているならpushでいいんじゃねえの

>>446
ありがとうございます。
当然その回答のみで確実性を担保する気はありませんが、他に似たような事を考えている方がいれば参考意見が聞けるかと思ったのです。
>>448 の方も言っているように Git はリポジトリの clone をローカルに持つからか、バックアップについての情報があまり出てこなかったもので・・・。

>>448
ありがとうございます。
社内のポリシー的なもので GitHub など外部のリポジトリサービスは残念ながら使えないのです。
社内に GitLab などを立てて複数 bare リポジトリを管理している方はこの辺り一般的にどうしてるのでしょうか・・・。

>>447
ありがとうございます。
git bundle を知らなかったので、調べてみたいと思います。

>>449
ありがとうございます。
やはりそういった運用になるんでしょうか。
そちらも検討してみます。

>>450
ありがとうございます。
GitLab を使用しているので、rsync で親ディレクトリから同期してしまうのが楽かな、と思って質問させていただいたのですが、仰るような動作を行うスクリプトを書く方が確かに安全かもしれません。
検討させて頂きます。

>>451
ありがとうございます。
git bundle を余り理解していないので、push or clone とどう違うのかから調べてみたいと思います。

TottoiseGitでバイナリファイルのコンフリクトを
解決しようとしてるんだが、
とりあえずA.binってファイルについて

A.bin.BASE.bin
A.bin.LOCAL.bin
A.bin.REMOTE.bin

って３つのファイルが追加された。
BASEだのLOCALだのと言葉が端的すぎてわからんし、うっかり書き換えも怖い。
どれがなんのファイルかって教えてくれ。

馬鹿には無理

実のところ、>>455もよくわかってない

>>456
ttp://www.google.co.jp/search?num=40&hl=ja&q=%22%E9%A6%AC%E9%B9%BF%E3%81%AB%E3%81%AF%E7%84%A1%E7%90%86%3B%22+site%3Atoro.2ch.net+tech

>>454
コマンドでしか使ったことないんで何とも言えないが
A.binを選択してチェックアウトすれば良いのでは
元に戻すならHEAD、マージ元に置き換えるならブランチ名を

>>458
そうか、やはりコマンドでやるのがいいのかな。
Tortoiseは便利だから、できる限りこれで完結させたかったんだが。
ともあれ、ありがとう。

>>459
> Tortoiseは便利だから、
> Tortoiseは便利だから、
> Tortoiseは便利だから、

Tortoiseは便利だよ

それなんて発音したらよいの？

発音記号見ればいいじゃない。

Tortoise松本

GitインストールしたときにGUIが付いてたんですがTortoiseは入れるべきでしょうか？

>>444
今さらだけどありがと。

結局リビジョン指定してやるしかないのかな?

cvsの時代から頭が固まってて訳分からん(´･ω･｀)

TortoiseGit-2012-05-20-d54d219-64bit.msi

git コマンドで、現在管理「している」ファイルを表示するにはどうしたらいいの…。

git ls-tree だろうか

Gitでコミットしたものが壊れるときっていつですか？
一応.gitフォルダを毎日zipでバックアップしてます

ファイルシステムの物理的な破損とか、書き込み中に電源が落ちたとか、熱暴走したとか、
宇宙線でディスク上のビットが書き換わったとか、まあ一般的な要因じゃね？
人為的には、うっかりコマンドの引数に*とかやって.gitも巻き込んで弄ってしまうとか。

>>470
zipでGitリポジトリをバックアップしている男の人って・・・

良スレ

>>427
あたしたちはtarでバックアップよね〜
男子ってありえなーい

>>470
sed -i に気をつけろ。

おれ、初心者なんで
git init --bare
git add .
git commit -m "はじめてのコミット"
git clone パス
しか使いませんよ
でもたまに壊れるんですよ

>>476
ベアリポジトリにaddする男の人って…

--bareってだめなんですか？
初心者入門サイトとかで--bareつけてたからおまじないでつけてたんですが

--bareの意味を調べるといい
とんでもない間違いをしてることに気づくはず

「おまじない」とかいう初心者向け解説は百害

まったくだ
あの文化は誰が広めたんだろう

単なる遅延評価じゃないのか

また騙された奴が居るクマ

まさか出来てしまうのかと思ってためしにやってみたが、ベアリポジトリにaddとかできねえクマ

まあそりゃベアだしな

>>480
あれは
・事細かに説明する手間を省いてくれる
・よくわかっていないことをごまかす
という二種類の意味を持つ呪文なので、どっちなのか見極める術を
読む側が身につけないといけないのでふ

とにかく呪いだの幸せになるだの言ってるようなのは
その言ってる人間が胡散臭いｗ

ベアに釣られまくりとかｗ

パリィ

>>486
つまり書いてる側にとっての「おまじない」なのか。

ブランチってこういう解釈でいいですか？

masterブランチとtest100ブランチがあるとします
masterのほうには汚したくないので汚れても良いtest100にいろいろコミットしていきます
あ！これでいいなと思ったソースコードが出来たらmasterに切り替えてコミットする

masterに切り替えてmergeだろ

はじめてのコミットをしました
そしてその後ソースコードをたくさん書き直しました12時間×３日分あります
このとき２回目のコミットをしないでgit reset --soft HEAD^をしました
そしたら１回目のコミットのときのファイルに戻ってしまいました
git reset --soft HEAD^をする前の状態に戻したいのですがどなたか助けてください

どうしてそんなになるまでコミットしなかったんだ(AAry

コミットに失敗してgitに入ってるデータと今編集しているコードが消えたらどうしようかなと思ってコミットしませんでした

作業ディレクトリをDropboxに置いてるとか、TimeMachine(OSX)とかなら。

git reset は現在のワークツリーの状態を一旦どこかに保存してから書き戻したりしますか？
No
保存されている場合、それを取り出して復帰させることはできますか？
だからNoだってんだろ

git reflog で表示されてないものを戻すことはできない

>>495
偽者乙
本物ならGitのこと信用できないってことだから使うのやめたほうがいい

ええええ
ここで聞けば助けてくれると思ってたんですが

GitHub for Windowsはどう？

今git checkout .ってやっても戻りませんでした

てゆかなぜ真っ先に2chで聞こうと思ったのか
2ch以外は信じられないのか？

> git reset は現在のワークツリーの状態を一旦どこかに保存してから書き戻したりしますか？
> No
これでFAだな
いちおうファイルシステム上で普通にファイル削除が行なわれているだけなので、
resetしてしまった直後に削除ファイルの救出を行なえばなんとかなったかもしれん

いずれにしても、コミットされてないものをgitが管理することはできない

　　　　　　 　 　 ＿_
　 　 　 　 , ‐' ´　　　｀`‐、 　 　 　 　 　 　 ／￣:三}
.　　 　 ／,. -─‐- ､.　　 ヽ　　　　　　　　/　　 ,.＝j
　＿,.:_'＿＿＿＿＿_ヽ、　.!　　　　 　 .／ 　 _,ﾉ
　 `‐、{　へ　　'ﾞ⌒　`!~ヽ. !　　　　 ／{.　　/
　　　 ｀!　しﾟ　 （　ﾟj　`v‐冫　　　, '::::::::ヽ､/ 　　　　そんなことよりBazaarしようぜ！
.　　　 {.l 　 '⌒　 　 　 ﾞ 6',!　　 / :::::::::::::::/ __
. 　 　 〈　　< ´￣,ﾌ　 .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
.　 　 　 ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠.　　 ヽ_}　 ﾞヽ
　 　 　 　 ,.r｀ "´　　／:::::::::::::::::::ィ´　　｀ゝ　 !、　　/
　　　　　/ 　 　 　 / :::::::::::::::: ; '´　　　/´＼　/ 　 r'＼
.　　　　 i　　　　　 ! ::::::::::::::／ 墨　|　.!::::::::／ヽ､.._!ヽ.　ヽ､
　　　　 {　　　　　 {:::::::::::;:ｲ　/　　 ‖ｉ:::::::/:::::::::::::/　 ＼
.　 　 　 ヽ 　 　 　 ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／

git reset --soft は HEAD の位置を変えるだけだし、
一回しかコミットしてないなら HEAD^ は存在しないんじゃないか？

実行できたのなら、本当はどっか1回コミットしてるかなんかなんだろうな
どっちにしても、コミットしてない部分は戻っては来ないが

コミットしてない部分は戻っては来ない地獄で悶えて氏ね

ばんばんcommitしちゃえってことだな

とりあえずブランチ作って移動しておけということ
masterを大事にするならなおさらブランチ作っておけ
ブランチにいくらコミットしてもいくら壊してもmasterは永遠に無事

git branch -D master

>>493
もう一回書き直せば、今度はもっと早く綺麗に書けるよ

>>493
もしも編集していたファイルをgit addしたことがあるなら、
念のためリポジトリをバックアップしてから
git fsckを実行してみたらいいんじゃないかな。
実行結果に「dangling blob」で始まる行表示されるなら
そこに表示されてるハッシュ値を使って
git show ハッシュ値
を実行するとgit addした時点でのファイルの内容が表示されると思う。

ねこでもわかるGit
これ誰か作ってください
アフィリエイト張ってもいいです
踏みますので初心者でもわかりやすい講座をお願いします

ググるといくつか出てくるけど。
https://www.google.co.jp/search?q=%E7%8C%AB%E3%81%A7%E3%82%82%E3%82%8F%E3%81%8B%E3%82%8BGit&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a

>>513
「猫でもわかる*」ほどくそな入門書はない

そりゃネコ向けだからな

うあ本当にあるんですね
ありがとうございます
さっそくそこみたんですが
git add *って書き方は　git add .　と同じでしょうか？
初心者入門サイトではgit add .　しかみたことないのですが

git add がどういうものかを調べようとは思わないんだな

. はgit add にカレントディレクトリを与えている。

*はすべてのファイルに展開せよというシェルへの指示。
結果的にカレントディレクトリの全ファイルがgit addに与えられる。

ということはどっちも同じって認識でよろしいでしょうか？

>>519
> *はすべてのファイルに展開せよというシェルへの指示
ホームディレクトリで echo *
（UNIX/Linux系列のみ）

ドットで始まるファイルは*では展開されないな。

カレントディレクトリ直下のドットで始まるファイルは展開されずにadd対象から外れるけど、
カレントディレクトリ配下に存在するディレクトリ下のドットで始まるファイルはadd対象になっちゃうのよね

あえてgit add *を使う必要は無いと思うけどなあ

だから git add がどういう意味なのか調べろって
なんでおまじないの扱いなんだ

管理したいファイルだけを追加しろってことだな
管理したくないファイルを追加「してはいけない」

もしかして git add * と git add '*' の区別がついてない人がいるのか。
Windowsだと付かないかもしれないけど。

git add * はシェルが * を展開、 git add '*' は git が * を展開、でよい?

>>527
正しい
そして>>526はこれの違いがわからない無知
最初から git add * だと書かれているのに

ここの常連でもレスが伸びるような話題だったから良い質問したんだなと思いました

git add '*'すると、git自身が*を展開してドットで始まるファイルも対象になるのかｗ
おれはunixでしか使って無いけど、こんな動作想像したこともなかったわｗ

さらに、カレントディレクトリに*にマッチするファイルがひとつも無い状態でgit add *すると、
*がそのままgitに渡って、gitがカレントディレクトリ下のドットで始まるファイルもaddしちまうのなｗ
これはシェルによっても違うのかも？

% ruby -e 'p ARGV' *
zsh: no matches found: *
% bash
$ ruby -e 'p ARGV' *
["*"]

おお、ほんとだ

.htaccessも含めて漏れることなく全てのファイルをコミットしたい場合はgit add .でいいですか？
初心者に1か0かはっきり教えてください

10です

>>517
全部入れるなら git add -A のがいいんじゃないか

多少関連する質問だと思うんだが、
日本人以外も * をアナルと認識するの？

コミットしたデータが壊れるようなコマンドって resetコマンド以外にないですよね？
resetにさえ気をつけておけばデータを壊すことはないですかね？

>>536
gc

>>535
すぐにググれば解決するのに。
聞くより先に手を動かさないからいつまでも初心者のままなんだ。

asterisk anus
と入力してみれば、検索候補にほら！

アナルって何ですか？

アナル管理地獄で悶えて師ね

>>538
ありがとうございます！
積年の疑問がすっきり解消しました！
これで今日からも楽しくアナルをほじれます！

アナルデビューとgitデビュー、どっちが敷居が低いですか？

アナル最高！

_________________________
　　○
((　(ヽヽ　　　　ﾝｷﾞﾓｯﾁﾞｲｲｯ！
　　 >_|￣|○
しまった！ここはホモスレだ！
オレが掘られているうちに他スレへ逃げろ！
早く！早く！オレに構わず逃げろ！

アッー！

a

質問です。

コミットログにおいて
中括弧 [ ] で囲まれた単語はなにか特別な意味でも持っているのでしょうか?

そのような単語を含むログを持つコミットから
format-patch → am で取り込むと
中括弧 [ ] で囲まれた単語が括弧ごと消えてしまうみたいなんですが、、、

>>547
中括弧？大括弧？

何と呼ぶかわかってませんが
この記号です。
[ と ]

>>549
[]は、大括弧|ブラケット
{} は、中括弧|ブレース
本題の、format-patchはワカラン。すまそ

]}*{[

アッー！

>>550
勉強になりました。
ありがとうございます。

>>547
以下 git am --help の適当訳

作成者名はメッセージの"From:"行から取得され、作成およびコミット日時は
"Date:"行から取得されます。"Subject:"行は一般的なプリフィックスである
"[PATCH <あれこれ>]"を取り除いた後コミットのタイトルとして使用されます。
"Subject:"行はコミットの内容を1行で簡潔に表したものであると想定されて
います。

>>547
手元で試した感じ、
s/Subject: [PATCH.*]$//
のような感じで最長マッチしてるっぽくて、最後の「]」までがすっぽり消える

ただし、Subject:がエンコードされて2行以上になっていると、2行目からは[]の中身は消えない

git branch -D hoge

を間違って実行して予定外のブランチ消しちゃった場合って、
戻し作業はreflogで頑張るしか無いですか?

何か頑張る必要ってあったっけ？
checkoutすればいいだけじゃ。

>>547
[ ] の中身も残したいならgit am --keep

>>556
hogeブランチに複数回のコミットがあったとしても

git checkout 削除時に表示されたブランチの最新のコミットID
git checkout -b hoge

で、元に戻るんですね

コミット全部を順番に戻す必要があるのかと思って勘違いしていました

ありがとうございます

>>547です。
みなさん いろいろと教えていただきまして
ありがとうございました!

TortoiseGit 1.7.10.0
Support for localization (you can download/create language packs for TortoiseGit, see http://code.google.com/p/tortoisegit/wiki/Translation)
よしお前ら頑張れ

>>412のサイトが息していないのが気がかりだ…

コミット、イニット、プル、フェッチ、プッシュ、マージ...
日本語化いらないよね〜ｗ

>>412
英語版(unicode版)のDLをおすすめします

>>562
とはいっても和訳されると逆に難解にならないか？

Gitでmergeするときに、あるcommitだけを除いてマージとかできないでしょうか。

たとえばリリースブランチを開発ブランチにマージする時に、リリースブランチ特有のコミットというのがあって（リリース番号を増やすとか）、
それは開発ブランチに含めたくないというケースです。
まあこれは全部をマージした後にrevertするという手がありますが。

あるいはリリースブランチと比べて開発ブランチが大幅に変更されている場合、
リリースブランチにcommitした複数のバグフィックスのうち、開発用ブランチにも適用したほうがいいものとそうでないものがあって、
適用しなくていいものは除いたうえで、リリースブランチの内容を開発用ブランチにマージしたいというケースがあります。
このようなケースでは cherry-pick を使った方がよさそうですが、cherry-pick だとどのcommitまでを開発ブランチに適用したかがわからないので、
できればマージを使いたいと思っています。

よろしくお願いします。

>>565
cherry-pickでマージしたあとに、さらにmerge -s oursでマージコミットだけ出来る

git stash save したのを git stash pop したら conflict したのでもとに戻そうと git checkout filepath したら
error: path 'some/where/file.txt' is unmerged
といわれてもとにもどせません。
こういうときどうしたらいいですか。
「git "error: path '*' is unmerged"」で検索してもよくわかりません。

一度現状のままaddしてからcheckoutしたらどうだろう。

>>567
どのコミットに戻すか明示的にすれば出来るかな

$ git checkout HEAD file.txt

>>567
git reset --merge
で stash pop 前に戻るはず

format-patchで作ったパッチに
定形文を挿入する方法ってないかな〜。

それぞれ独立したsvnのリポジトリがふたつあって、
git svnで使ってるんですが
その両方に自分の担当しているモジュールが存在しています。
片方では普通に開発、
もう片方にはformat-patchをあてるだけ、、、
でやってます。
面倒なのは、パッチをあてたあとに
「どこそこリポジトリのリビジョン◯番から持ってきたコードです」
とコミットログを追加しなきゃならんことなんですが、
なんかうまい方法はないでしょうか？
パッチのコメント部分を自分で置換するしかないでしょうか?

>>571
git am してるって事かな。それなら無理そうだねぇ
通常の手順でログを書き換えるなら

git cherry-pick --edit
git merge --squash

くらいかな。

git-svnのSubversionの外部参照のサポートはまだですか
dcommit相当を毎回ほぼ手動でやっててそろそろ死にそうです

トートイズ・ジット(TortoiseGit)って口にしたらクスクスされた。死にたいorz

ｸｽｸｽ

初見で
とーたす
って読めるひとっているんだろうか

タートイズという読みが癖になってしまった。

さいきんになって
テストコードのようなものを書き始めたんですが、
まずテストをコミット、
その次にそのテストが通るようなコミット、
、、、というように
分けてコミットするのが一般的なんでしょうか？

方針によるんじゃね？
どのリビジョンを抜き出しても全テスト通らないといけない縛りがあったら、一緒にコミットすることになるだろうし

>>576
フランス人はトータス以外の読みを知らない

トータスってバンドを知ってたので馴染みがあった

tortoise松本

GIF画像をジフと呼んでたからgitの文字見るとジットって言ってしまう。

ジットでもあってる
ギットじゃなきゃダメって言う方が情弱

俺の顔油もギットギトやで

はたらけど
はたらけど猶わが生活楽にならざり
Git手を見る

Gnu的にはイットだな

>>572
やはり無理ですか。
ありがとうございました。

なんというかうちの開発体制がまずおかしいんですよね〜orz

>>566
>cherry-pickでマージしたあとに、さらにmerge -s oursでマージコミットだけ出来る

merge -s ours がぐぐってもよくわからんけど、これってどういうものなの？

他のブランチをマージして、
マージで生じた変更を修正して消去した…そんな感じのコミットを作る？

その結果として、HEAD^とHEADはまったく同じ内容だけど、
ブランチをマージしたという記録だけがHEADに付加される。

bitbucketのアカウント取ったんでTortoiseGitから操作したいんだけど
msysgitっていうのはインストールしないとダメなの？
TortoiseGit＋bitbucketのみで問題ないならmsysgitっていうのはでき
ればインストールしたくないんだけど・・・・・・

git fetch origin refs/foo/bar
git checkout FETCH_HEAD
を一つのコマンドでできんの？

gitでHEADを動かすコマンドは、
checkoutコマンドとHEADの状態を更新するコマンドと、
それ以外に何かあるかね？

merge -s ours ってコンフリクトしたら自分優先って意味であってる？

コンフリクトも何も相手の変更は何も取り込まない

そんなバカな、と思って試してみたら
本当にコンフリクトしてないところも取り込まれてなかった

gitってもしかして他のユーザがリポジトリにcdしてチェックアウトすると
他のユーザが書き込めるディレクトリならそのユーザが所有するファイルが
リポジトリのディレクトリにぶちまけられるから、マスターと同期するだけの
クローンを持ったユーザを作って作業するユーザは更にそこから
リポジトリのクローンを作るというリッチに立地を占拠する使い方が必須になるの？ｗ

頼むから日本語で話してくれ

なんかしらんけどGitHub使え

このご時世に潤沢にディスク無いならgit使うの諦めとけ

msysgitを使ってますが、ホイールでスクロールさせるにはどうすればいいでしょうか？
別にインストールしたcygwin(TERM=xterm)ではホイールスクロールできているんで、
Git\etcのどっかの設定ファイルをいじってターミナルを差し替えればできるんじゃないかと
思っているんですが。

.xtermrc

>>601
Git Bashのこと言ってるのなら
スタートメニューに登録されてるGit Bashのプロパティを開いて
オプションタブの簡易編集モードにチェックを付ける

Windowsでtig使いたい場合ってCygwinしかない？

tigってなんやねん

ggrks

oh...gitのtypoだと思われる可能性は考えてませんでしたすみません
コンソール上で動くgitリポジトリブラウザです

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

web+db

github

ttp://hirocaster.github.com/wdpress69/

ヒロキャスター

環境毎に違うDatabase設定ファイル等は、どうやって管理するのが通例ですか？
clone時には設定ファイルも欲しいですが、その後管理から外したいです。
git rm --cached kanri.phpしてpushするとリモートリポジトリ側からもkanri.phpが管理外となってしまい、
以降のcloneでkanri.phpが取れなくなってしまいます。

設定ファイルのテンプレをrepositoryに含めて
実際の設定ファイルの置き場所は別にして.gitignore

>>614
clone後にテンプレをコピーして環境用に編集ということですね。
そういう手で行っているのですね。

ありがとうございます。

新しくgit portableをインストールしたので古い方のgit portableを削除しようとしたのですが、
なぜかgit --versionで確認したら新しい方のgitのハズなのに古い方の/etc/gitconfigを読んでいます
一応動作に支障はないし古い方を消せばいい話ですが、なぜこんなことになってるのか
分からないのが気持ち悪いです。
原因は何だと思われますか？
ちなみに/etc/configにパスは通っていません。~/.gitconfigにはなくetc/gitconfigだけにある設定な上に
リネームすると読み込まなくなるのでetc/gitconfigを読んでるのは間違いないと思います

>>616
gitコマンドのバイナリの中に、環境変数やオプションでの指定が無い場合は、
/etc/gitconfigから設定をとってくる処理があるだけじゃないの？
UNIX系のコマンドなら普通のこと

知らない振りして質問してスレを盛り上げるのが 2ch の流儀。

$ git push -u origin master でエラーが出てプッシュできません
こんなエラーが出ます。原因を教えていただけませんか？
Username for 'https://github.com':
fatal: could not read Username for 'https://github.com': No such file or directory
shell returned 128

origin を
[email protected]:HOGEHOGE/FUGAFUGA.git
にするんだよ

ああ。本当ですね。thx
でも何でだろう
https://github.com/xxxxx/yyyyy.gitの形式でもリモートに登録できていたハズなんだけど

最近出来なくなったみたいだお

git svn dcommitで .. resource out of date; try updating .. なんちゃらという警告が出た場合、
ここで言うupdateってのは git svn rebase をやり直せってことでいいですよね？

ところが git svn rebaseしようとしても、First, rewinding head to replay .. ということで
やたら古いコミットを巻き戻そうとしてコンフリクトしてしまいます。
履歴はこんな感じで、そのコンフリクトするファイルにmasterとgit-svnの差異はありません。

* (HEAD,master)
* merge
|\
| * (git-svn)

svnリポジトリの方でそのファイルが更新されたわけでもないようですが、こっちの
gitリポジトリがなにかおかしくなっているんでしょうか？

>>623
git-svn するなら、mergeコミットがあったらダメですよ

なるほど、そういうものなんですか。今までもこのようにやってきたんですが、たしかに
git svn rebaseが成功したときは一本線の履歴に書き直されていましたが。
ただ気になるのが、今git svn rebaseしようとしてコンフリクトを起こすのが、ここで
マージされているブランチが分岐した時点よりずっと古いコミットだというところですね。
なにかこの状態から回復する方法はないでしょうか。

>>625
とりあえずマージコミット以前に reset して rebase するとか、
git-svn (trunkかもしれない)ブランチから再度やり直して、masterにある必要なコミットを
cherry-pickしていくのが地道だけど確実なんじゃないかな。

そうか、そういうことができるんですね。subversionから移ってきたばかりで
感覚がつかめてませんでしたが。
試してみます。ありがとうございました。

>>627
svnやっていたなら逆にProGitとかちゃんと読んだほうがいいですよ
どうしてもsvnに当てはめて考えちゃうので、いったん概念をリセットしたほうが理解できる

gitは普通の企業じゃ流行らへん気がするな
使うのにcygwinとかmsysgitとか入れるのを面倒くさがりそうだし
macとまで言わんから会社でもせめてunix系のos使いたいわ

普通の企業 == Windowsしか使わない

これからは統合環境にgitが入ってるのが普通になるだろ

EGit便利

>>632
1〜2年ほど前に試した時にはステージングやdiffやrebaseやコミット指定が使いづらくて
結局コマンドラインに戻ったんだけど改善した？

しかしEGitはまだいまいち信用ならん気がする

githubにプルリクエストしたらリベースしてまとめろって怒られてしまいました。
やったことは：
フォークしてローカルにコピー。
日本語訳用のブランチを切って作業。
日本訳部分を修正してコミット。
放置してたらフォーク元のリポジトリが更新されたのでgit fetch upstream;git merge upstream/masterで更新。
(これは日本語訳用のブランチでやってしまったかも)
日本訳部分をまた修正してコミット。
フォークした先にプッシュ。
プルリクエスト。

githubのプルリクエストには
hage 日本語訳のコミット1 96d8373
hage Merge remote-tracking branch 'upstream/master' into 日本語訳用のブランチ a253255
hage Merge remote-tracking branch 'upstream/master' into 日本語訳用のブランチ 45325c1
hage 日本語訳のコミット2 673bb56
みたいに表示されてます。

それで↓を参考にgit rebase origin masterまでしました。
ttp://qiita.com/items/cddd7dd9cde6a9c6dde6

git rebase -i でエディタに出るコミットとgit logで表示されるコミットで混乱してます。
"日本語訳のコミット1"96d8373と"日本語訳のコミット2"673bb56の間に
"Merge remote-tracking branch 'upstream/master' into 日本語訳用のブランチ"a253255や45325c1は存在しません。

どうしたら1つにまとめられるの?

>>635
そのままrebaseすればいいんじゃないの
a253255 とか 45325c1 とかが適用済みの master に rebase するんでしょ
最悪 git diff で取り出したパッチをあてるとかでもいけると思う

> 放置してたらフォーク元のリポジトリが更新されたのでgit fetch upstream;git merge upstream/masterで更新。
pull request しようとしているブランチでこれはやっちゃだめだと思うよ

>>635
rebase -i した時に次のようになるんだよね

pick 96d8373 日本語訳のコミット1
pick 673bb56 日本語訳のコミット2

一緒にしたいなら squash (s)に書き換えて

pick 96d8373 日本語訳のコミット1
s 673bb56 日本語訳のコミット2

エディタを閉じるとさらに新しいコミットログ入れろと来て、
エディタを閉じるとコミット1にコミット2が足されて
一つのコミットになると思うよ。

>>636
>a253255 とか 45325c1 とかが適用済みの master に rebase するんでしょ
そうです。
そのまましようとしたけど、rebase -iで96d8373と673bb56の間にはa253255と45325c1が無いのでどうしていいのか分からず質問しました。

>pull request しようとしているブランチでこれはやっちゃだめだと思うよ
寝ぼけたせいか、やっちゃったようです。

>>637
pick 96d8373 日本語訳のコミット1
pick 5366d33 他人1のコミット
pick 553accc 他人2のコミット
pick 3673ddc 他人3のコミット
pick 673bb56 日本語訳のコミット2

みたいになってます。この他人1,2,3のコミットはa253255と45325c1ではありません。
s 673bb56 日本語訳のコミット2 にしたら僕の日本語訳のコミット2は他人3のコミットに含まれちゃって困ったことにはならないのでしょうか?

>>638
おおう、なんかややこしい事になってるね。
mergeしただけなら間の3つは出ないはずなんだけど、なんだろう。

自分のコミットが2つだけってわかってるなら
最新のmasterからブランチ作り直してcherry-pickした方が早いかもね。

git cherry-pick -n 96d8373
git cherry-pick -n 673bb56
git commit

-n オプションつけるとcommitをまとめられます。

>>639
ありがと。なんとか一つにまとめられました。

特定のcommitに非常に大きなファイルが追加され、git pullが失敗します。
そのcommitあるいはファイルを無視してgit pullを行う方法はないでしょうか。

いちおうgit format-patchは試してみましたが、やはり失敗します。
なお原因のファイルは別途リポジトリから持ってくることはできました。

>>641
fetchは出来るの?

fetchもできません。同じようなエラーが出ます。
エラーメッセージは控えてないですが、サーバー側でOut of Memoryが
発生したとか、そんな感じでした。

『サーバー側でOut of Memory』の解決にはならないかもしれないけど、再転送は防げる:
こっちで適当な捨てブランチで add & commit してから pull してみるとか
むこうの .git/objects からそのファイルを持ってきてコピーするとか
こちらの .git/objects の適当なファイルをコピーしてごまかすとか (危険)

ありがとうございます。単純に特定のcommitを無視してfetch/pullするようなことは
できないということですね。
ところで、pullするのはその捨てブランチ上で、ということでしょうか？その場合、
masterを同期させるにはmergeする必要があるのでしょうか？
それとも、対象のファイルをadd/commitしてしまえばmaster側でpullできるように
なるということでしょうか。

>>643
圧縮中に失敗してるのかな？メモリ不足っていうのなら
サーバー側のリポジトリに以下の設定をしてみたらどうかな

圧縮用のメモリを50MBに制限

$ cd /git/hoge.git
$ git config pack.windowMemory 50m

それでも足りないなら圧縮用のスレッドを1つに制限

$ git config pack.threads 1

>>特定のcommitを無視して
--depth で shallow repository なるものを作ることができるらしいので、それで可能かも。

捨てブランチで add & commit してからの pull は本番ブランチの方で。

git svnでcloneしたものの中に、編集中(ステータスがM)のものがある時に、rebaseやdcommitする方法は無いでしょうか？

stash?

stash以外だと無いでしょうか？
その編集されたファイル（ステータスMのもの)は、dcommitやrebase時以外は編集状態にしておきたいのです。

stashの何が不満？

stashだと、編集内容が退避されてしまうことです。
常に編集状態にしておきたいのです。でも、dcommitやrebaseはしたいのです。
dcommit前にstash、dcommit後にstash popとするような形になるのでちょっと面倒です。

>>652
単に手間を省きたかったり、stash popし忘れを気にしているなら
stash -> dcommit -> stash pop
を一度にやるシェルスクリプトやバッチファイルを書いて使えばいいのでは。

はい、手間はそれではぶけますね。ただ、gitの何か標準の方法で何か同じことができないかなーと思ってました。
ありがとうございます！

そのスクリプトのファイル名をgit-xxxxにしてパス通しておけば
git xxxで使えるようになるぜ

へー、そんな気軽にサブコマンド作れるんだ…

>>652
ああ、なんかわかるよそれ
git stash saveっていろいろオプションあるけど -no-revert(仮)だけないんだよな…

一旦ワーキングコピーをクリーンにしないとrebaseでコンフリクト発生時に困るからじゃないかな

はたらけどはたらけど
猶わが生活樂にならざり
ぎつと手を見る

Git の読みは「ジット」で良いんですよ

むしろなぜ「ギット」なわけ？
読みづらいんだけど

うふふ

きもいです

英単語を日本人の発想で読みにくいとか言ったってしょうがないでしょ

あいだをとってゲッツでいいよ

コーヒージフトはエィジィエフ

ぎっあんつ、ぎっあんつ、ゆけゆけそれゆけ

くるー、ギットくるー

ギトギト油は徹夜明けによく出るよな。。。

会社の仕事でも
git使うことになったんだけど、
コミットログを英語限定にされてしんどいよ〜

いまどきは英語ができて当たり前なのかもしれないけど、
俺の場合、コミットログの英文考えるのに時間が取られるorz
日本人しかいないのに何故英語？って聞いたら
文字化けするから、だって、、、

svnならどうかしらないけど、
gitには文字エンコーディング関係の設定もちゃんとあるのに文字化け問題なんて存在しないよね？？？

>>670
> gitには文字エンコーディング関係の設定もちゃんとあるのに文字化け問題なんて存在しないよね？？？
正しく設定すれば。
その会社の面子にその設定をする能力が無いと判断したのであれば、それは正しい。
そのルールを作ったのがそれを知らなかったのなら、そいつがだだのギット。

オプソでgithubとかに上げるなら英文で書く意味も有るけど
仕事でやってたら効率下げるだけだなー
楽天じゃ有るまいし

コーヒージフトはエィギィエフ

fa-sutokomitto

>>670
その会社、普段からUTF-8とSJISとEUC-JPが混在してるんだろうなぁ…

　 　　　　 |
　 　＼　　__　　／
　 　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　 　　　　|ミ|
　 　 ／ 　｀´　 ＼
　　　　　('A`)　　　　日本語のログをファイルに保存してコミットしよう
　　　　　ノヽノヽ
　　　　　　　くく

ファイルの先頭にコメントで日本語のログを書こうぜ。

ローマ字「………(ﾁﾗｯ)」

1行目だけ英語、3行目以降は日本語(UTF-8)で書いてる俺が優勝

優勝おめ(棒)

1行目は60文字くらい以内でコミットを要約
`Add a new class Hoge'とか`Refactor the method Foo.bar()'とか
(マージコミットに生成されるメッセージと合わせるため主語省略・文末のピリオド省略)
2行目は空行　3行目以降に必要なだけ詳細説明(各行は70文字くらいに抑える)

git始めて半年くらい試行錯誤した結果がこれ

これ？ｗ
https://gist.github.com/3160352

>>682
あちこちのwebページ見て試行錯誤したけど、上のはどこか1箇所のスタイルをほとんど継承してるはず
いただいたリンクは似てるけど違うようだ

初めてコミットしたものを消したいんですが消えません。
どうやって消せますか？
git init
touch test.txt
git add .
git commit -m "a"
git log↓以下が表示される
===========================
commit 11d20268befb62d7d53d818e36e5368549c124f8
Author: xxx <[email protected]>
Date: Wed Jul 25 08:37:00 2012 +0100
===========================
git reset --hard 11d20268befb62d7d53d818e36e5368549c124f8 もしくは git reset --hard HEAD^
git log←コミットしたものが消えてない

git commit --amend

rm -rf .git
git init

>>684
git log HEAD^で確かめてみればわかるが、
HEAD^は存在しないから、git reset --hard HEAD^はできない。

git reset --hard 11d20268befb62d7d53d818e36e5368549c124f8は、
git reset --hard HEADと同じ意味で、
今の状態に戻すということだから何もしない。

gitで一度行った変更をなかったことにする方法4つ
ttp://labs.timedia.co.jp/2011/02/git-various-undo.html

http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB
ここを見ながらsubtree mergeでサブディレクトリに読み込むとこまでは行ったんですが、
サブプロジェクトRackがさらに別のプロジェクトをsubmoduleで取り込んでる場合は
どうすればいいんでしょうか？
rack_branchをチェックアウトしてgit submodule init > git submodule updateすると
submoduleが読み込まれるんですが、masterを再度チェックアウトすると空のままなんです。

貼ったリンク間違っていました。正しくは、こちらです。
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%84%E3%83%AA%E3%83%BC%E3%83%9E%E3%83%BC%E3%82%B8

add . と、add -A には意味の違いがない同じコマンドと見なして良いでしょうか？

はい

>>691
違うぞ
git add . は削除ファイルがステージされない
git add -A は削除ファイルもステージされる

-A はベンダーブランチみたいな運用をする時に重宝するよ。

git reset HEADのHEADを省略した場合はHEADになるんですよね？

gitgでコミットした人のアバター（gravatar.com）を表示するようになってるのですが、これを停止する方法はないもんでしょうか
っていうかこれ画像はキャッシュとかされてるんでしょうか、まさか毎回コミット表示するたびにサーバに問い合わせしてる？

あれはgithubを見るときにも表示を遅くして非常に鬱陶しいので、hostsに
127.0.0.1 localhost.localdomain localhost www.gravatar.com secure.gravatar.com gravatar.com
と書いてしまってる

今時Win板hostsスレを参考にするなんてかっこわるいよ
AdBlock系でgravatar.comをブロックとかの方がスマート

>>697
> も

>>695をなんとかするには>>696みたいな方法しかないはず
githubで表示されなくなるというのは余録に過ぎない
DNSのブラックリストを弄れるソフト導入してるなら別だが

>>698-699
あの…AdBlockPlusとか、Operaならデフォルトで「特定のドメインへのアクセスを遮断する」機能がついているんだけど
「>>696みたいな方法しかない」というのはどこで誰が主張しているの？

>>700
何でgitgとウェブブラウザが関係有るんだよ
何か他のものと勘違いしてないか

こんなわけわからん主張でスマートとか言い出すやつに何言ったって無駄だと思う

hostsは万能なのにな

git stash save で、特定のファイルだけを指定してsaveできないかな。
すべてをsaveする仕様は使いづらい。

>>704
git stash --patch とか？

stashにまで-pオプションあんのかよ、、、

>>705,706
さんくす。--patch は add -p と同じ意味なんですね。

設定ファイルみたいにclone時には含めたいけど、
pushさせたくないファイルってどうすればいいんですか？
--assume-unchangedはcloneとかresetで元に戻ってしまうみたいだし、
clone毎に設定しなきゃならないとヒューマンエラーの元になりそうだし。
〜.ini.sample作って〜.iniをgitignoreに入れとくしかないんですかね？

そうです

>>708
setting.ini.inでコミットしておいて
configureでsetting.ini.in -> setting.ini
を生成するのが一般的かな。

>>710
> configureでsetting.ini.in -> setting.ini
というのは、プログラムレベルとかビルドの話ですか？

>>711
ビルド、というかビルドの前処理ですね。

ローカルでtest.txtを作り
git add .
git commit -m 'hoge'
git push origin
と行ってもリモート側にファイルがPUSHされません
リモート側でステータスを見ると
git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: test.txt

となっており、何故か勝手に削除されているようです
既に存在するファイルを変更してPUSHしても変更が元に戻されてしまいます
どこを見ればいいかもわからずアドバイス頂ければ幸いです……

リモートにpushしたから、test.txtがリポジトリにのみ存在して
リモートの作業ツリーに存在しない状態になっているだけじゃないの？

githubさんがメアドの存在性チェックを始めちゃったみたい

何か都合悪いのか？

変えるの面倒くさいから、なくなったメールアドレスがデフォルトだよ
どうすべｗ

Account settingsからEmails選んで、新しいメールアドレス追加して、
古いアドレス削除すればいいんじゃないの？
2つ以上メールアドレス登録してあれば、Default消すと他のアドレスがDefaultになるんじゃない？

うん

>>713
>>714の言うとおり作業ツリーが更新されてないだけでpushはされているよ。
リモート側で git reset --hard すれば同じになる。

.git/hooks/post-receive に

(cd ..; git --git-dir=.git reset --hard)

といったフックスクリプトを書いておけばpushした時に自動で更新出来る。
変更ファイルは吹っ飛ぶけどね。

でも、pushはbareリポジトリに使って
non-bareなリポジトリはお互いにpullし合うように使うのが基本だと思うよ。

>>718
こんな事件もあるみたい
ttp://news.mynavi.jp/column/svalley/476/

tagつけたのにsf.netのブラウザ上で表示されないよ

去年10月にコミットした状態のディレクトリを/tmp/10gatu/
に取り出したいのですが
どうすればいいのでしょうか

>>723
レポジトリが/path/to/reposにある場合
% cd /path/to/repos
% git archive --format=tar (10月のcommit-id) | (cd /tmp/10gatu;tar xf -)
でどうでしょう

>>722
tagをpushしてないとか。

質問なのですが、gitのレポジトリはどのディレクトリに作成していますか？
/var/lib、/usr/local、~/以下など何か慣例はあるのでしょうか。

>>726
慣例は知らないけど、SSHだと下記のようなパスが多い気がするので

ssh://example.com/git/hoge.git

うちはルートにシンボリックリンクを作ってそこを参照するようにしてるよ。
実際の置き場所はまちまち。

/git -> /home/public/git

>> 727
なるほど〜。シンボリックリンク自分では作ったことなかったんで超参考になりました。
ありがとうございます！

>>726
gitの場合いろんなとこにできるからなぁ。
センターはバックアップ送りにしたいので/var/rep/gitとかに、ローカルは~/usr/gitとか~/tmp/gitとかにしてます。

普通、gitliteとかでリポジトリをつくってバックアップだろ。
生gitのレポジトリをそんなに使いたいのか?

アドミンの好きにすればいいけど、面倒だろ。

ローカルは好きに、cloneに時間掛からないなら、毎回消しているな。
もちろん、自分のbranchやstashが必要なら消さないけど。

UTF-8-MAC問題が修正されてるね
precomposeunicode = true

github:gistでhttps://gist.github.com/3401612のように文章で太字やらリストやら見出しやらを付けたいのですが
ページ内のrawというリンクをクリックするとソースみたいなのが出てきます
それを参考にして自分でも書きたいんですがhttps://gist.github.com/でLanguageは何を選べばできるのでしょうか？

Markdownじゃないか

githubでローカライズ用の1ファイルだけを更新してpull requestした(マージもされました)のですが、
同じファイルだけ更新して2回目にpull requestする時は新しいブランチを作ってからpull requestしなければならないのでしょうか?
日本語化だけのブランチなので英語版が更新されるたびに新しいブランチを切るのも面倒な気がして。

↓の話はpull requestが取り込まれた後も影響するの??

GitHubへpull requestする際のベストプラクティス - hnwの日記
ttp://d.hatena.ne.jp/hnw/20110528
>>1点だけ、pull request後の注意点があります。pull requestに使ったブランチで別の作業をしてはいけません。万一無関係なcommitをpushしてしまうと、pull requestにも反映されてしまいます。

馬鹿には無理

　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

2回目にpull requestする時は新しいブランチを作る地獄で悶えて市ね

>>735-737
この人何か嫌なことでもあったの

GitHubのissue報告のページにはどういうマークアップ記法が使われていますか？
コードの部分をそれと分かるようにしたいです。
プレーンテキストオンリーは嫌です

>>739

Comments are parsed with GitHub Flavored Markdown
リンクはってあるやん

>>740
本当だ
ありがとうございます。

PortableGit-1.7.11で
git pull --rebaseをしていると、
/libexec/git-core/git-sh-setup: line 266: cd: .git: No such file or directoryというエラーが出ました。
ファイルgit-sh-setupの266行目を見ると、
test -n "$GIT_DIR" && GIT_DIR=$(cd "$GIT_DIR" && pwd) || {
echo >&2 "Unable to determine absolute path of git directory"
exit 1
}
とありますが、つまりこれは$GIT_DIRがないということでしょうか？
このあとどうしたら正常に動かせるようになると思われますか？

福沢諭吉「脱亜論」　１８８５年３月１６日 時事新報

日本の不幸は中国と朝鮮だ。
この二国の人々も日本人と同じく漢字文化圏に属し、同じ古典を共有しているが、
もともと人種的に異なるのか、教育に差があるのか、 日本との精神的隔たりはあまりにも大きい。
地球規模で情報が行き来する時代にあって、近代文明や国際法について知りながら、
過去に拘り続ける中国・朝鮮の精神は千年前と違わない。
国際的な紛争の場面でも「悪いのはお前の方だ」と開き直って恥じることもない。
もはや、この二国が国際的な常識を身につけることを期待してはならない。
「東アジア共同体」の一員として その繁栄に与ってくれるなどという幻想は捨てるべきである。
日本は、大陸や半島との関係を絶ち、 欧米と共に進まなければならない。
ただ隣国だからという理由だけで特別な感情を持って接してはならない。
この二国に対しても、国際的な常識に従い、国際法に則って接すればよい。
悪友の悪事を見逃す者は、共に悪名を逃れ得ない。
私は気持ちにおいては「東アジア」の悪友と絶交するものである。

　　　　　　　　　_,,,,,,__　 __,,,__
　　　　　 　 ィｊｊ）））))))))!!!!!彡ヽ,
　　　　　　/ﾐ/　　　　 　 　 ,}彡ﾍ
　　　　　　|ﾐ{ -‐ ‐ ‐　‐-　 {三=|
　　　　　　El=＝; ﾟ　''＝=.　|ミミ,|
　　　 　 　 `ﾚｆｫ､,〉 :ｒｆｫ.､, 　!ｉﾙ┤
.　　　 　 　 ｛ ｀¨ i　･､¨ ´　 `{ゞ'｝　支那、朝鮮とは
.　　　　　 　 |　'`!!^'ヽ 　 　 .｢´　　付き合うなと忠告しておいたのに。。。
　　　　　　　 !　,-ﾆ'¬-､　　,!|,_　　　
.　　　　　　　 ＼´?｀　　／ ∧ﾍ、
　　　　 　 　 __/〉｀ー ' ´ ／　 〉　＼
　　　　 _, ィ´「∧ 　 　 ／　　/　　　 」¬ｰ- ､_
　 -‐ ´　 /　/　 ヽ､／ 　 　/　 　 　iヾ　　　 　 ヽ

以下の様な場合どのようなコマンド・処理が適切でしょうか？
状況：パソコンAで少しずつ修正をかけて、パソコンBでそれを見る
パソコンAから共用リポジトリへpush→共用リポジトリからパソコンBへpull
という操作を繰り返すことになるのですが、
そうするとコミットの履歴がどんどん増えていくことになります。
なので、共用リポジトリに前回pushした内容を上書きする（１つのコミットを修正し続ける）ような形にしたいです。

＞そうするとコミットの履歴がどんどん増えていくことになります。
何が問題なんだ？

共用リポジトリを使わず、git-daemon とか使ってパソコンBでパソコンAから git pull -f すれば？

>>744
作業用に一時的なブランチを生やして作業、最終的にまとまったら--squashでマージ

scpとかデプロイツール使う局面なんじゃないか？

>>744
ftp put / getというコマンドが適切。

>>749
だせえｗいまどきFTPかよｗｗ

>>750
だせえやつには、だせえものを。
自分ならgitかnfsかrsync。

台湾を救った陸軍中将根本博
http://www.youtube.com/watch?v=RRYOmM-TlKo
台湾の歴史
http://www.youtube.com/watch?v=8ahxYuYwGIc
台湾の歴史1(〜13まであり)
http://www.youtube.com/watch?v=NGE8ZWYy8XQ

>>751
レンタルサーバの多くは「お前らユーザはダサいんだからFTPだけ使わせてやる」なんだよなぁｗ

747以外全部とんちんかんに見えるのは俺だけか…？？

うん

>>747のやり方では履歴が増えちゃうだろう。

>>747は
・増えるのはブランチの履歴だけ
・git merge --squashしたら、後はリモートのブランチ削除
ってことでしょ
それでいいとオレも思うけど

正しいことを書いても全力で否定するのが2ch流

>>757
共有リポジトリに何度もコミットするってあるよ?

githubで通常のプロジェクトとgistの違いはなんですか？
一方でできてもう一方でできない(ないし困難な)機能はありますか
どう使い分ければよいですか？

gistはpastebinサービスの一種で、基本的に単一ファイルを貼るもの
gistに貼ったものは、ブログとかにもそのまま転載してsyntaxhighlighterの代わりにしたりできる

>>761
なるほど　ファイルが一つかどうかで使い分けるのがよさそうですね
小さいファイル複数で構成するので通常のプロジェクトを使いたいと思います
ありがとうございました

複数ファイルも扱えるよ>gist

>>759
共有リポジトリでmasterブランチにマージしなけりゃ履歴はいずれ消える。
マージするときもsquashなら増える履歴は一つだけ

>>764
それじゃ最後までmasterに入れられないし、入れるまではbranchの履歴が増えてくじゃん。

履歴増えるのはどうでもいいけど
複数のcommitを一回のcommitにあとからまとめる方法ないかな

>>766
squash

それだとあらかじめ連続するcommit専用のbranch作っておく必要があるよね

rebase

>>769
ありがとう
超thx!!!

>>766
http://labs.timedia.co.jp/2010/11/git-squash-commits.html

>>768
作業用と公開用の履歴わけたいのかと思った。rebaseこそbranchある前提じゃ。

ある程度commitしたあとでやっぱり新しいbranch作っておけば良かったとか思った時どうしてます？

>>773
基本、次からそうしようと思うだけだけど、必要なら過去に戻ってbranch切ればいいんじゃないの。

必要なら過去に戻ってbranch切るのとrebaseってどうちがうの？

rebaseはbranch切った後の変更も保持されるでしょ。rebaseはその名の通り、branchの分岐した根元を移動させるものだと思ってるが違うのかな。

　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

gitでリモートのブランチを取得するにはどうすればいいですか？
マシンAでブランチを複数作成
↓
リモートに反映
は出来たのですが、
マシンBでリモートからブランチを取得することが出来ません
git pull origin で無理でした。
試しに、マシンBでリモートのブランチと同じ名前のブランチ（hogeとする)を作って、
git pull origin hoge : hogeとした所、
ローカルのhogeにリモートのhogeをマージしましたみたいなのが毎回出るので
別のbranchと認識されていると思います。

馬鹿には無理

>>779「えーっと、マジでやり方わからねえけどいじりてぇ…しかたねえ『馬鹿には無理』」

馬鹿には無理

もっとアナ・コッポラちゃんに罵られたい

>>778
結論から言うとそれで問題ない

$ git branch -r
で出力されるのがリモートブランチ
「origin/master」と「master」は別のブランチだから、同期するにはマージの必要がある
コミットのIDをが同じなら同じ位置にいるブランチだと確認できる

「origin/master」と「master」の２重管理で悶えて師ね

>>778
最初、ローカルのhogeが無いときにpullしちゃだめだぜ
git fetchなりした後、git branch -rでリモートブランチorigin/hogeがあることを確認して、
その後、以下のどれかでローカルのhogeを作る

git branch -t hoge origin/hoge
git checkout -t -b hoge origin/hoge
git checkout -b hoge origin/hoge
git checkout -t origin/hoge
git checkout hoge

全部同じローカルブランチhogeができる。まあ一番最後が簡単だね

馬鹿には無理

いやん、ばかん、うふん。そこは、branchなのっ。

いやっ、だめぇ！そこbranchなのぉっ！

エリコ with branch

テスト

王様のbranch

え？今そのギャグ！？

rebaseしたらout of memory出てそのブランチのコミットが全部吹き飛んだよ。
reflogから拾ってなんとかなったけど、
--abortも効かないしこのエラー処理はいただけないなぁ・・・。

原因はうっかりコミットされた数百メガバイトのファイルだったんだけど
大きすぎるすぎるファイルをadd出来ないようにするとか出来ないかな？

ファイルサイズ調べて上限超えてたら弾くwrapperでも書いたらいいんじゃね
alias設定しとけば使い勝手もたいして変わらんでしょ

git イイよ、git。手軽に始められるのがいい。
みんなに気に入られていてWeb上に情報がたくさんあるのもいい。
好きなコマンドは、git initです。

ネタなのかマジなのか

git stash 難しい…。
以下の処理だと、最後のstash popの時点で、
「CONFLICT (content): Merge conflict in c.txt」。

mkdir stash_test
cd stash_test
git init
echo 1 >> c.txt
git add c.txt
git commit c.txt -m "1"
echo 2 >> c.txt
git commit c.txt -m "2"
echo 3 >> c.txt
git commit c.txt -m "3"
echo 4 >> c.txt
git commit c.txt -m "4"
echo index >> c.txt
git add c.txt
echo work >> c.txt
git stash -k
git stash pop

気持ちとしては、「index」行の追加がインデクスに残って、
「work」行の追加がワークツリーにある状態に戻ると思ってるんだけど。

>>797
stash [save] -kがなんなのか俺は知らんけど、これがついてなかったら
stash pop --indexでインデックスの状態含めてpopしてくれた気がする

>>798
ありがとうございます。
pop --indexでやってみます。

-k(--keep-index)はインデックスの状態を保持してstash。
git add -p とかしたときに、インデックスの変更点だけでテストが通るか試すのに便利。

あとコンフリクトについては
http://stackoverflow.com/questions/4058372/git-stash-and-edited-hunks
が参考になるのでないかと。

>>798
できました、できました。ありがとうございます。
最後の2行を、

git stash
git stash pop --index

にしたら、希望通りの動きになりました。

-k（--keep-index）を、indexを保存することと勘違いしていました。
どちらかというと、保持する意味合いだったようです。

798さま、ありがとうございました。

>>800
レスが前後してしまいました。
-kは、その場に残しておくことを指定するオプションだったんですんで。
今考えてみればそのとおりですが、
なぜか、indexを保存しておく、という意味合いで捉えておりました。

URLも参考になりました。

ありがとうざいました。

>>796
いいやつだよ、init。
他のバージョン管理は使ったことがないので比較はできないけど、
git initで、コード管理が始まる手軽さがうれしい。
おかげで、ぐっちゃぐちゃだったドットファイルとか、書きなおす勇気が湧いた。

>>802
× -kは、その場に残しておくことを指定するオプションだったんですんで。
○ -kは、その場に残しておくことを指定するオプションだったんですね。

お礼レスでのタイポ失礼しました。

home directory で git init 最強

>>805
個人用のlibとかどこに置いておくんだ。
etcとusr作って、そこだけ履歴管理してる。
でもcvsと違ってmoduleでcheckoutできないから、ちょっと悩む。

最強は/.gitに何かマウントしておいて/でgit initだろう。

>>807
履歴付きのファイルシステム使えよ。
tmpとか履歴取る意味わからんし。

ひだまり荘で待ってます
git initくださいね

>>808
そんなあなたに
.gitignore

>>810
そういうレベルの話でなくw

git branch -a すると
remotes/origin/HEAD -> origin/master
remotes/origin/master
というのが見えるんだが、この２つの違いは何？

デフォルトのブランチ

コミットする前に変更した部分(差分)を確認したいのですがどうしたらいいの?

git diff --cached

github終わるん? (;_;)

>>816
は？
「Gitという一過性のソフトウェアに依存しているサイトだから
あと数年でGitが廃れたら終わるね。sourceforge万歳！」
とか答えればいいの？

これのことだろ。
Rackspace sued for hosting GitHub
http://lwn.net/Articles/516736/

どうなるかは知らんけど。

bitbucket大勝利

とりあえず今のうちに git clone --mirror しとけってこと？

>>818
ああこれか
俺は「この程度でGitHubは潰れない」に賭けるね

英語わからんから三行でまとめて

いきなり申し訳ありません。

東京x１〜大阪x２の計３台のマシンにgitをインストールして
ソースコードの管理をしようと考えています。
※全てWindows環境なのでmsysgit + Git Extensionsをインストールしてます。

全てのマシンでクライアント利用が出来ることは確認できたのですが、
(githubにアクセスして任意のリポジトリをclone出来た、という意味です)
各マシン間でのソースコードの公開をどのように設定すれば良いかが
判りません。

東京のマシンを中央リポジトリとして、３台のマシン間でソースコードを
管理(push/pull)したい場合は、どの様に設定すれば良いでしょうか？

ネット上では、msysgitをクライアント的に使用する方法は多数出てきますが、
マシン間をhttpプロトコルで公開する方法についてはほとんど出てこない状況です。
※sshやWebDavでの公開方法は見つかったのですが、ＬＡＮ内であるということで、
　プロトコルはhttpを利用したいと考えています。

過去スレや設定方法が載っているURLでも結構です。
本スレ256周辺に近い話が載ってましたが、難しいでしょうか・・

みなさんのお力を貸してください。
宜しくお願い致します。

読みなおしてみると判りづらい部分がありましたので、補足します。

私が知りたいのは、msysgitとapacheの設定(連携)部分です。
msysgitでcloneしたリポジトリは、どの様な設定をすれば
httpプロトコル経由で他のマシンに公開できるのか？という
部分がしりたいです。

お願い致します。

>>822
TechCrunch日本語版に記事があるけど、それかな？ちがう？

>>823-824
HTTPで閲覧できるGitのリポジトリ公開用サーバをmsysGit+Apacheで作りたいって話だろ？
キーワード msysGit Apache でぐぐっただけで
・Hosting a Git server under Apache on Windows
・Gitリモートサーバー(for 勉強環境) on Windows 構築メモ
とか色々出てくるんだけど……

ていうかWebDavはHTTP（の拡張）だろ。WebDavじゃだめでHTTPでやりたいとは？

>>823
リポジトリをwebdavとして公開するようにすれば使えますが、
gitらしく動くようにするにはgit-http-backendも設定する必要があります。
(詳しくは git http-backend --help や git webdav http-backend で検索)
apacheならこんな感じの設定ファイルになります。

---/etc/httpd/conf.d/git.conf------------------------
SetEnv GIT_PROJECT_ROOT /var/www/html/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
<Location /git>
Dav on
</Location>
-----------------------------------------------------

windows+msysgitの場合はgit-http-backendへのパスなど調整する必要があるでしょう
試した事ないので動くかはわかりません。
でも、
・WebDAVは遅い
・認証する場合apacheの設定が面倒
・認証パスワードを保護するはSSLが居る
と、面倒事が多いので
仮想マシンにLinuxを入れてSSHしたほうが楽かもしれませんよ。

ssh が一番簡単で楽

ssh鯖も仮想マシン作るよりmsysのsshdで充分

>>828です。
git-http-backendとwebdavが一緒にいるみたいに書いてたけど必要ないですね。
勘違いして自分のサーバーも間違って設定してた。恥ずかしいorz
正しくはこうです。

git-http-backendで公開する場合。GET/POSTだけの純粋なHTTP
---/etc/httpd/conf.d/git.conf------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
-----------------------------------------------------

webdavで公開する場合。/var/www/html/gitにリポジトリ
---/etc/httpd/conf.d/git.conf------------------------
<Location /git>
Dav on
</Location>
-----------------------------------------------------

>>823が知りたかったのは上の方ですね。
適当なこと言ってすみませんでした。

皆さん、返事が遅くなり申し訳ありません823です。

>>826さん
ありがとうございます。
どちらもヒットしたのですが、上のURLは英語、下のURLは内容を読んで
実行していたのですが、CGIスクリプトの辺りで理解できなくなり断念
しておりました。


>>827さん
WebDavはHTTPの拡張プロトコルだったのですね。以前、自宅サーバを
構築した時にApacheとは別で設定したので、別物だと思っていました。
勉強不足でした。


>>828さん
詳細かつ丁寧な情報ありがとうございます。書き込みを見てすぐに
理解できるほどのレベルではありませんが、内容を自分なりに精査してみて、
こちらの方法を試してみます。


>>829さん　830さん
どうしようも無くなった場合にはsshでの構築を考えたいと思います。
アドバイスありがとうございました。

皆さん色々な情報提供ありがとうございました。
また、何かありましたら質問させて頂きます。

>>828さん

823です。
申し訳ありませんが、一つ質問お願いします。

上に書いて頂いた、/etc/httpd/conf.d/git.confの設定は
ディレクトリ構成などからLinuxでの設定と考えてよろしいでしょうか。

Windowsにインストールした、msysgitフォルダ配下を検索しても
git.confというファイルは出て来なかったもので・・・
仮想マシンにLinuxを入れてSSHした、と仮定しての設定という事ですね。

よろしくお願いいたします。

>>830
msysのsshdってあるの？

To answer your question: install cygwin, and use its package manager to install sshd.

cygwin+meadowでgit-blame.elだったかを入れたら、vc-annotateで-rlocalとかいうオプションつけられて動かなかったでござる。Linuxで仕事してぇ。

馬鹿には無理

sshd は cygwin で git は msys にしとくのがオヌヌメ

今、cygwin の sshd なんだけど、msysのsshdがあるならmsysだけですむかなと思っただけ。
馬鹿には無理ならいいや。速さが変わるわけでもないし。

>>833
833です。

はい、Linuxでの設定です。
git.confというファイルは自分で作ったファイルです。
例のように３行だけの設定ファイルです。
Windows版のApacheにはconf.dがないのでhttp.confに直接
git-http-backendの設定３行を書き足すだけでOKのはずです。

Linuxのhttp.confには下記のように

Include conf.d/*.conf

というincludeの設定が最初から書かれていてconf.dに新規ファイルを
作成するだけで独自の設定を追加出来るようになっています。

↑828です。もうダメポ。

自演してるとアンカミスるよね、

情弱乙

githubでプライベートリポジトリ買った方が早いと思う。
msysgitのgit bashでgit daemon使えなかったっけ？

gitblitだとJava製なんでWindowsでもそれだけで使える

git-daemonは認証がないから仕事用には難があるな

823です。

皆さん、色んな回答ありがとうございました。

本日もhttpで通信しようとして、あれこれ設定しましたがうまく行きませんでした。
Cygwin入れてSSHで、というお声が多くありましたので、月曜日にやってみようと
思います。

833さん始め、みなさんありがとうございました！

>>763
まじか！知らんかったわ…

>>839
msysgitとCygwinのgitって速さ結構違わないか？

だれも Cygwin の git を使うとは言ってない

>>847
828です。
なんか気になって来たんで自分でもやってみたよ。

1. http.confに設定を追加
-----------------------------------------------------
<Directory "C:/Program Files (x86)/Git/">
Allow from all
</Directory>
SetEnv GIT_PROJECT_ROOT C:/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ "C:/Program Files (x86)/Git/libexec/git-core/git-http-backend.exe/"
-----------------------------------------------------

2. システム環境変数Pathに追加。C:\Program Files (x86)\Git\bin

3. ファイアウォール設定。ポート80の受信開放。

で、動きました。でもちょっと遅いですね。

828です。
折角なんで色々な組み合わせで速度を測ってみました。

clone時間(転送速度) OSとgitサーバーの組み合わせ
-----------------------------------------------------
10.939s(18.60 MiB/s) Win7 git-daemon/msysgit
17.903s(12.54 MiB/s) Win7 ssh/cygwin+msysgit
25.110s( 2.08 MiB/s) Win7 apache/git-http-backend/msysgit

9.018s(18.67 MiB/s) Linux git-daemon
9.106s(18.56 MiB/s) Linux apache/git-http-backend
9.519s(20.77 MiB/s) Linux ssh
-----------------------------------------------------

gitサーバーはWindows 7上のVirtualBoxのゲストとして作成し
Win7 = Windows 7 64bit (VirtualBox)
Linux = Scientific Linux 64bit (VirtualBox)

別PCのLinux(Scientific Linux 64bit)で
仮想マシンのgitサーバーからcloneした時間を測定しました。
time git clone git://vboxaddress/git/git.git
time git clone http://vboxaddress/git/git.git
time git clone ssh://vboxaddress/git/git.git

テスト用のリポジトリにはgitのミラーを使いました。
git clone --mirror git://git.kernel.org/pub/scm/git/git.git

ひとつ気になるのだが、httpでロック機構がないと同じタイミング
でpushすると、ぶっこわれないか? davだとlockがある気がするが
ほかどうのさ。

svn checkoutのように特定のリポジトリから特定のリビジョンを
バージョン管理外へ持ち出したいのですが、
gitでこれをするには一度リポジトリをcloneし
欲しいリビジョン以外のデータも全てコピーしてから
git checkout hashする必要があるのでしょうか？

>>818
あー、これか
コレでgithubがサービス停止で俺の有料分リポジトリがパージされたら日本の裁判所に訴えるしかないのかな

> 854
man git-archive でよくないか?

>>849
Cygwinのsshdとgit使えばmsysgitいらなくなるじゃない！

>>854
その特定のリポジトリとやらから同じことすれば。

>>853
git本体ががCGIとして呼び出されてるだけだからsshと同じじゃないかな。

>>855
訴えるべき主体が国内に存在しないので訴えようがない。

>>857
Cygwin の git はイマイチ

会社でgithubエンタープライズ使ってるけど、これ一人2万もするのか
たけえな

> 859
それは、.git/hook/post-update が git update-server-info
を呼んでいるが、CGIだと並列に呼び出されることはないと
いっていますか?

>>863
CGIではpost-updateにupdate-server-infoを仕込む必要なないので
呼び出される事はない、かな？

ななんだって

git clone --bare でつくったリポジトリはどうやって更新したらいいのん？
git pull したら、「ワークコピーがなかろうもん、バカちん」的なことを言われた。

他のリポジトリからpushすればいいのでは

ありがとう、やってみる。

元祖にpushする予定と、しない予定のあるプロジェクトがある場合は

リポジトリを二つに分けてpushする予定のあるリポジトリから

forkでpushしない予定のリポジトリを作るというような

理解であってますでしょうか？

分ける必要は無いと思いますが、お好みで分けてもいいのではないでしょうか

>>869
日本語でおｋ

それだとforkとbranchの違いがはっきりしないね

remoteRepoから、localRepoA と localRepoB を clone して、
localRepoAからのみ push すればいいんでないの？
違う？
もしかして、cloneもとは２つある？

それはforkとどうちがうのでしょうか

>>870-873
あざす

他のスレでもbranchを使えばという話になりました。

馬鹿には無理

git-svnでSASL認証が使えるものってありますか？
普通のgit-svnにSASL用のモジュールを組み込めばいけるのでしょうか？
OSX環境ですが、Linuxでもいいです

>>877
単にsubversionがSASL有効でコンパイルされてないとか
svn --versionしてSASL authenticationって出なかったら
git-svnでも使えないんじゃなかろうか

githubで日本語モードにできると書かれているサイトが複数あるのですが
切り替えられません、いまはできなくなったのでしょうか？

馬鹿には無理

>>879
翻訳間に合わねえから英語のみにするはってアナウンスがあったような

現在ブランチAを作ってそちらで作業しています。
まだ区切りがついていないのでコミットいません。
しかしマスターに更新したい箇所があります。

git checkout masterとしてもブランチAの変更は消えないでしょうか？

ok

>>882
消えないです。
ってか、別でディレクトリ作って簡単なテスト環境作って試したら？

ブランチAで作業中の修正をmasterのワークツリーへ持っていくことになるぞ？
ブランチAでやってる作業とはまったく関係無い修正をmasterでするなら、git stashを使うのがいんじゃないか？
git stash saveでブランチAの中途半端な修正を一時的に保存してからmasterへcheckout
masterでの作業が終わったらブランチAをcheckoutしてgit stash pop

>>882
「ブランチAの変更は消えないでしょうか？」これの意味が、
ブランチAでコミットしてない修正が、checkoutしたmasterブランチのワークツリー上でも存在し続けるか？
ブランチAに戻ってきたときに、ブランチAのコミットしてなかった修正がワークツリー上に残ったままか？
どっちの意味だ？

馬鹿には無理

　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

Githubに接続しようと公開鍵を登録した後、

ssh -T [email protected]

を入力しても、

/.ssh/config: line 1: Bad configuration option:　鍵〜〜

となり、接続できません。
どうすれば接続できるんでしょうか……？
稼働させているのは仮想OSとしてたてたRedHatです

>>889
~/.ssh/configに変なこと書いてない？

鍵〜〜のところに表示される内容がまるまる載っているんですが…

また例のひとこと来るぞ

BOMでも付いてるんじゃない？

横レスだけど、BOMの有無とか文字コードとか改行コードってどうやって確認するんだっけ？

hexdumpやodなければバイナリエディタ

>>895
やっぱりそれか
自分はnkf -gで文字コード調べて、
バイナリダンプの先頭付近見てBOM判定、ダンプの中で0D0A検索して改行コード判定してるけど、
この方法よりよさそうな方法はないっぽいのね

少し気の利いたテキストエディタなら、ファイル開くだけでステータスバーに全部出るんじゃないの

>>896
viで開いたらすぐ判る

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

find. -type f|xargs file

新しいテキスト ドキュメント.txt: UTF-8 Unicode (with BOM) text, with CRLF line terminators
今のfileはこんなんまで表示してくれるのかｗ

これは知らんかった便利だなｗ

https://github.com/norinori2222/boyfriend_require

githubで彼氏募集するというの斬新すぎる

＞年齢：30代後半

理想高いなー。

年齢より金

この条件に当てはまるほどの人間がこんな面倒臭そうな女に人生の時間を費やすとは思えないね

>>903
吹いたｗ

ステマかと思ったが、単なる釣りだろ。

ライセンスｗ

>>907
なんのためにgithub選んだと思ってんだよ
pull requestでバージョンあがるたびに条件減らされまくるっていう自虐ネタだろ

アプローチ方法はネタでも彼氏ほしいって気持ちは本気だろうよ

ガチホモ

>>910
そんな仕込みもｗ
やべぇバージョンあがってるかちょっと見てくるw

>>911
これで彼氏が見つかったら映画化されるなｗ

彼女募集だったらネタ乙だったけど彼氏募集だからな・・・
ホモのお人かと思ったけどしっかりと女性って書いてあったのが残念

そして、全米が感動の渦に

issue２０件わろた

SourceForgeの新システムって、機能が明らかに退化してるなあ。
Githubはいいなあ。

今も昔もSourceForgeが使いやすかったことなんてあったか？
ファイルひとつダウンロードするにもリンクを何重にも辿らないといけないクソ設計じゃん。

githubいいね

なんかファイルの日付が全部今日になっちゃったぞ

それがどうかしましたか？

>>921
日付が変わるとすごい困るんだけど
差分出来ちゃうじゃん

?

Gitは基本的にファイルのタイムスタンプはガン無視なので…
後付けでタイムスタンプも保存する機能くっつかないものかのう

んなアホらしい機能、誰得だよ

なにムキになってんの…

test

せめて手元に引っ張ってきたファイルのタイムスタンプは
コミットされた時の日付になってはほしいということ？

関係ないけど、ブラウザのダウンロードでもLast-Modifiedヘッダの日付へ
タイムスタンプを変更するかのオプションくらいはそろそろ付けてほしいｗ

branch に checkout して戻ってくるだけでも日付変わるけど
(共通のファイル以外)

どうでも良いけど
せめてダウンロードしたファイルのサイズくらいチェックして欲しい
途中で中断して黙って完了とかアホすぎる
firefox とか

pass

pas

コミットするときにタイムスタンプをテキストに保存するしかないのか
うまく自動化できそうだな

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

まあそうなるわ

保存しとかなくてもファイル毎に最後に変更があったコミットはログから分かるんだからそれに変更するスクリプト書けば良いんじゃないの？

天才北-

>>936
お前馬鹿だろ？
それだとコミットした時刻になっちゃうだろ？
お前はファイル修正した瞬間にコミットできるの？
マッハ20で動けるの？

現状: ファイルがチェックアウトなど変更される時点での時刻にされる
>>933: 保存時のタイムスタンプがコミットに記録される
>>936: コミット時のタイムスタンプに(あとから)変更する

>>938は>>933の方法で記録されたタイムスタンプに(あとから)変更するスクリプト書けばいいと思うの

ソースコードの場合はファイルの日付が過去になると
make とか ant とかのファイル更新検知が機能しない(再コンパイルされない)から
チェックアウトした日付になってもらわないと困るんだよな

>>940
元のファイルの日付で何か問題あるの？

OSによるけど
ぴったり元の時間に戻したつもりでも
２秒くらい過去の時間に変わってたり

>>941
過去のコミットに戻った時に、日付まで戻られるとmakeが破綻する

>>940
手元でコンパイルするなら、いちいちチェックアウトするなよｗ

サーバ側でやらせるなら、クリーンビルドしろよ。
横着してると問題の発見が遅れるぞ。

git用語としてのcheckoutを混同してる予感

makeやant使うにしてもcommitされたものはcleanなものだから全部作り直しじゃないの。

checkoutは横レスじゃないのか?

日付は常に最新に変わってもらわないと、
タグでチェックアウトして確認する時に差分コンパイルが出来なくて困る。
git bisectも効果的に使えない。

checkoutしたらその時間になるのは当たり前だからいいとして、
git archiveでアーカイブを作ると、全部のファイルのタイムスタンプが最後の
コミット日時になってしまうのがなんとかならんのか。個々のファイルごとの
最終コミット日時になるようにできないものか。

>>944
過去のコミットをチェックアウトしないで
どうやって過去の物をビルドするんだ
あんたGit使ったことないだろ

タイムスタンプをコミット日時に変えた所で何に使うんだ
定期的にこういう事言う人いるけど

>>943
別に破綻しないだろ。何いってんだ？

>>951
一度git rebaseでも体験してこい

>>950
ん？そういう意味で言ったんじゃないんだが、誤解させたようだな。

タイムスタンプに関しては同意。

今更だが”チェックアウト”が具体的には何さしているのかよく分からんが、
どこかからか新しいコードを持ってきたら、まっさらな状態からビルドしないと
後々問題が起きた時に面倒だろ。

>>953
間違えた・・・俺>>944な。 orz

馬鹿には無理

↑バカのクソレス

>>954
gitの世界ではチェックアウトといえばリポジトリ内でのブランチ(任意のコミットやタグでもいいが)の移動ことだが、
おまえ、svnとかのチェックアウトと勘違いしてるだろ

自演してるとレス番間違うよね

svnだとupdateが作業するコミットを変える操作で
switchが作業するブランチを変える操作

gitはどちらもcheckoutを使う
hgだとどちらもhg updateだっけか

馬鹿でも分かるような、
ムービー付きのGITのGUIを作ってやれよ

>>960
スライドで充分じゃ

http://www.amazon.co.jp/dp/4798035009/

http://rogerdudler.github.com/git-guide/index.ja.html
http://osc-tokyo-git.phper.jp/
http://slashcolon.com/pdf/ProGit.pdf
https://docs.google.com/file/d/0BxkaLAGEeWgLNDRhYzQ3MDgtNmQ1NC00ODZiLThmYzYtYmJlYWE5YzY2Mjkw/edit?hl=en
http://www.textdrop.net/doc/git-cheat-sheet-ja/
http://www8.atwiki.jp/git_jp/
http://gitref.org/
http://www.amazon.co.jp/dp/4798023809/
http://fnya.cocolog-nifty.com/blog/2012/04/git-4b11.html
http://tech.kayac.com/archive/git-book.html

手元のソースをリポジトリから引っ張り直したのならmakeはcleanしてからmakeするだろ普通。
リポジトリでファイルのタイムスタンプまで保持したら別の変更とマージしないといけなくなった時に
どちらのタイムスタンプを取るのか困るだろ。
という事でファイルのタイムスタンプはコミットされた時刻にするべき。

>>964
> 手元のソースをリポジトリから引っ張り直したのならmakeはcleanしてからmakeするだろ普通。
は？

>>964
　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

>>964
>>964
>>964
>>964
>>964
>>964

eNptWNeS40aWfZ+v6NDEarqEmiUAgjBRakXAE44kDOE6+gHeew+t/n1R1T0asxsMEOTJkzevSXPz/jWrg3IKo0+/LlkdNsvw3+l
vf/nrn+BeZv4H0vZeUnmfgqaqonr8fMCvP300Hs9PL3+Zmyz85KNIGAVNGH2mHIP99Es4jK9ZPX4asj16/Q4NffDy+8fPg/wVB7
99+R384y1u+u9dhi/ga/YFfMt+hY4v4Av88nuQev2nX/wvP5Gut4MEAJxOP719kMMv/tcMgL79/Xh9A6B/SgkOCcGv4VsAAC/vw
3y0B3//G/C3b18GIHgbgC/h2x/v9Hftvo/3ruPpfIwJ/NAv+Ip8e/sHJz84+a/IW340B1/zb1/exX4+jPma/YIA+bd32S//dZjz
dth8YGfgsOzz5+Ar+O3XX+GXn8EVBOPg5X/eIejbb78hH9D55U869J0OHXTkBx38TocP+ncJ8T/p8Hc6fNDR7/TgnR58PX/79PM
ncD0f3D/+eNe88rL6wwQveP3uyl+8+YeJ5X5Y8e3LT5G4jzUD61c5MBOSHTReHMuxCjaRVfpxcsnFuZtPUx1VtsZTE6SU51Qu5i
RpZO4HsCjWTOIAy43jWrPtbf4EEMyNIDGlCt2Y2+/h/VEvy2PBBYondo2uAWuPKY/VKbAoFAPOBHRN7rrUxghEl41O9Xf2Hoh5T
5ZVYA9NCiWBM54RYVBVGkxGkBnj0KMLymVVHext8UnKI2k2ZxfK6DBiVAUAqaiF1kj0GXKVeq483luXyp4oqw5/8y7pIXegoAxf
wzZx+NIrz1BtUYNi3JyhIwKLBGcW3Ug+BbicrYjeGemw7+moMeMcsOxCUYIsm5/syUYcLvAEdJ7FwUszJORaB2FNl6eWFNWCk1F
YOlQwyXkybxYNk/x8XcWtYG/w0AhXSWjX6Ik69mnLBoTzSmC+TW73CG9QbSCMLjf1TAMDsKa8ty5WYbkTzGJFgGKJSSBP43T3z0
UWn1lxm4AxfEqIpA/uDorBep2qzbUExu43Te5lLenOfgiDDsrlJuZU5Mg0t9vlHrh6O4S+TAroGKzcfXVXmb/SghJJi8+j62GOj
Qgh4zMNY7dzQfiWAQCP7Loe7tYn8frQjOzUZShcN1LUBWnQlYXSMZjUOClvHoairo55g5n7WA7KBA/Kspw26yqS7t3L7NgXh46s
aH13V1Q6jynQQmld03Vj3cWylscuDMIwIpXRyot7wY3VNiposd/62z0H1nHibgNTqFYAFEElWPi2XQrvudP4iCJm4rCBkj0ywS2
bFgLUK4H4GXVT2SEte/m+Yn10N51VftpEBFsQP2kXx/T6y31j76RiQjV94aV7Gy5dYN6tczILgQsOJ8sGmw4lTDIBqIsLypTrol
xYnWLPDl0fNgUH6qPeHLinO5QLWtZS3x8TycUtc+OFsI2nCprGdvazc38hc7cEvRznZvWM0eXlpnAcBCDJUgam+6wk3JYLuTOQy
rinnT2YjEZpniWq02Ow9Aw686RmbHLlEW4loTeZQ1ecdyy+YrRNbINrUFpc0wyQEqNNcyujcjaffm1S2F11sMLtggo9cckwDisK
WlPPOeNTZjC6KgWrL7Nsc1sVZcPUCrqxra2nGE2h25RcOT+eS5+bvo3S2sVlawOrkRJ4bFi5XXjPRb3kRBlR2o++I9p8ag9ql52
j3eUVWfEl1VmsB1RJhGdBVy31qzJ94tUAZlLrbIq49FNrc0XsigjnXl2xmEtnLmWuWsRu8RAjTqocSgWXMsc0No5lmQy6C43SHt
LN2HHJ9VxqDwvfp9zcRVrQfK2mT2Te7SBaye3d46+rG7qZKFkNkZPLzEeL1h6LhHbmbI0HHRgeXt+tiMwd+sCToZIOfZWV+jJno

R1ZxcUt131hoccoYhg+wru6lwobZPMkweCmbQxHqdPZRVznyqbUDZPVkwmHLn34t16qXpaslrD7cAsL20WlNAZ6M8tr2ERrh7Bg
uN/Ola9MWE1ELs7LmbNAAKoGE/iAHt7ICe64QZmOEYdyWgfoo4fa7oU/nQZo1C4MYQCef9n2yGnhXr+ekrB5SjogdW2+zxrRgHW
7QKUKYpC+Int3cWd+dcz+kdzDadd4UiQioGcfMe4xLgvYrKFDkNB4RN7eMFgD9HLj8uV0J9xNvi/X9DQ/U9+SZZTTQvWUyzchNE
z0Fgh6XdgmMrUPPTLOD6Dt9lGxytybIXIWdK/vWRk9ZijYO1HhF+ItG3Rw8M2LGMGFBeO9fmmPdQa72uqJPsZOvgmLsSYXBFjN5
6gjbE10YHlfT1wo6ECnSE9v9/GYEzBZV8ttOgNJiZVS0FgO8aCuwq3l8TtsziMSYkQa9ydGb+r16mKtvqY31GSsETRidHVw2cw3
VyBR9DlYdrqea2fISdLiTm0mlVaZgSbJZa2rKy3EVfDSFpJ2Td1+UDrOUAn5jj+I+HZE1cg6Y9yIqWQtHxignRJqV6mNwSBpy9c
KIkzsxCyL/Gr2FtVSoXFCU2/yeJXA8pZHdi4hEOiK3QnqkdEQ0GT8ZnnlVehaYAcX5sYNT+5yHeNR7zPak1VphR9A444Vw8V9C2
5YpUDR5foIHndZcwmWHQuZ5Fe4mkjdsog82+7PYs7jCbjUFws0MXn1FDxaeAmLY6lgxzmdUsC26LV8uvoU4AuBLdEaKULmoFs70
oCm3ZTrUOneYDkjrAWzRYUtIU3X4epjjy1aJ1Rx9ds5f7oaJPOGYCzbdm0JpevGgbHUPLVQKpYA5gaVeHmzcOHWk17aAxrsQExM
4FYgrecBvwbPCxob0nDC7iM3Q81Dw1wGOV/TFhfO9YM1NtrhzLVd7RZUuvOdhmyCm9vVj83oYu7NirrpaKbyyTpO7SDzAd8Xt1x
znZmjypQaoUrzagIbkFjq7hm6msm6ZjczINEC2usVuUPGlVMV3+lAB6aofg0Y3pJghKpm7YIZ2dgzQ7NXqucwxMSo0R48FN9QfF
x7CDc3GbFIBk4zxijTrOlhdb/kO6aZD5MY5rFUc/tKlMKxcckeQgWaaGVO/pydYulQ/OhiLCG95jXnjRfVUDmGnJ8UxmcA75gWV
IBG2gETRJw2QYDRQ2h9IkACJK0eug1uUxhDpV49ogKcli1dMYHOS1c/L550K5MeIfh9KPViMfuVXXqjpp0e6oICyEtAPJ/hUVdv
Zj0yGurUnJBLI9CrSXFOLBqZL8dRjvbRzHhbFQfmaFrwskZn86kgwoZPjGWpJ30TSDPZewewxyOdIoDjLLlELO0IZVwQ1qVuGbL
S1hSL/Z3RrkAJM31/d5EL43slF0cKc6w9treyFhDopXWuvRnLXjOhqY6z5kUGdWuTkzW5hWhatIPU0E/KEmCblUk26SYf6ZsluV
lLv5U5aZgVKQ3pg65Ejl77NoaHY2Mggd6LRQfyH/4GzWeSteTQBloJSaEneOvquzz3vS66dyKs9rj00+yZhHCAS/1wLRrFvOHG1
SopWK0Vm7foJn1EKeBep+J8fqb66sXTPKwG/tgDbIRA72wfy5DzLT3MHQ0IENe8G4UhsJ1BZfZ0N+ezWcDZLOImnsvNVZ/12A0G
ppdo+EnM2L0K1rSxLqspn8hbtgbxSCmZrpDTEIyUpQsjUIEqSmx4Vyaae+wVqn5mTpw6Bhc4Y6/NxUv8umCf2tlTThpitvDA9vt
zlnG54loV4E17JrG1F32+NVVCDHgaalQtvtMWuRMsrGrKtQBlOONucXXl+tYB/SWB/Es73Cn7iZagzhB2GxE2GJcJgEu+dHEwEA

FAjI0cMd6o8FYaZdkYE7pxdg1hLe3LpxGTZAST7vOZnYJiB4DrOOeG2bNPAUi4xhd3tjkZ07FLHIuo3nDf57O5XXTQhkmzlR+pV
8GBme3ZQj/FhqlHNzz+7QNvc1W6ygDJtOr0RDJsDJTyHlB7tjM9l1QhziPZTqLZTTNV/+GuXTLbqruec/R0wzocO3KzxjQlgiq4
nMAutnIRZuUxLnVP+BBrnE47GcSZXcxgbQN8l6tzoY1O44blk9saPd16Xlqydg+dSEPDZS1HsReRi5TJq7lUPAISKldSR1JASWn
vnjfkiLIengzR6Lm1hFzocfS85Hw/1ckqF97l9jjLhMzPWo7yd6VSRBhYRTri+UcCcKHv2rKxnLgjrw6EDMrmvsHL/sY84zgqAr
t6QJaQFxbFLaJb8QBgGcoJ769t6BsLIbcgNkGitOUFENzEhi6VmcqW+rnH947w6FynyL7fSaRFgSJc81MPgax1yrl6VZXoZJ05s
MAfinKWrnC0dvqNFsk4WEIrnZTWjVowp1dntnT+mskXxrzDpZHFt21YzQDDInxPvDbT+SKG8Agup5TbY5yzrNvjtKYoaeuw2Dwo
9bhJYc+TuBAOcBWCVcxcQ1+qznwibWcCJ57lQBGXjCQqs62qLoS1bFrthJGpRwktYc/5klua4pbEE32K3PNq1oIN2ewglzkWdeF
FshQZ0N73jFbLZ1PrreN0iZNtMLlwQsHKOGPp3i0XSNM4zBIu136awRDOcBldC9snjnRjxtWHqM2H9dVwwtHG8g2UPSEF2GPd5V
kEhEqr6MVyS1VsiVCWI50Vy9kFi/ZZREs2WKEIdlyapDpFyQ+nvmAS/0jNe8hSLqI8nPjIp3FeB5iubDjfpTyGvo/LpawMzNloL
RbLQgIjdUJvCy3x+qTFTDhmuimON38WE9UamAVkfIN4pFhkhS68ouPpWvFpGyqJkl8TqNWAKDVREM6j1eNLcCOXYb7p8KIJ0DGr
ElBnz4OcgCznY8lgdZx2h2SqQgQjRaOW4byLSwiK0RXU6NTCdTD2UYJK4yL5w5kH94BGEPGMn7ZBjgYUUaEjF528SSdsdbORJ8p
gdamjqH1O/GPeBq1rbBZ65y9V7PoPPKuF00LH+oJEP2pB5Y5hX88wdP729s8q1Dv4+g6+vlc6Xr4z/Sn+CmNnFPz2Nh236yT+KE
99+YDesvjzVAdN1fbRMHw+qK8/fxSv/pT08tJH49TXn6C3q3VjPqVLHX7ho5GJhmJsWuujhvb55e3K0J/SMPhooj+/s35gVVQdM
N1H3hjRx0DemPll9M4Jg4NCCYZCPj4dF6L2/5CobKy89p34ioLg66Hvv3RoyvC9z+cfwIselVEw3v38+P78fdTXd6kvb8cNgir/
xMDj80Paq3UVDPbG6vrL278Xxz5cAwAv/14Ow9CPetjhs3efZr9gKJB/+5NTfAFfqy8QjL8Vvx4PALxWv/32BfoP+s/Voen4yNa
o/IdG+S84ULxmrx9FsPj9OSKXfdf5PxT+Fxt0jabvD+fl7f81/Lt3Xt6Yo3GM/tH4L9B7AD64L2/aAXhD9CNsrx9x+RF08O2P/w
UBPgSo

これが今話題のウィルスへの指令書か

>>964
日本語でおk

checkoutでファイルが1つ変更されただけでも
全てのソースファイルをコンパイルし直していたら
時間が掛かりまくりんぐじゃないか
その間2chでも見てダラダラ過ごすのか？

パルミジャーノ・レッジャーノ

>>972
プロジェクト分けてライブラリ化したら。
ソースが変わってたら困るだろ。diffで差分取って、違うのだけコンパイルするとか。

>>974
　　　 　 ＿__　　　　━┓
　　　 ／　—＼ 　　┏┛
　　／ノ　　(●)＼　 ・
.　｜　(●) 　 ⌒）＼
.　｜　　 （__ノ￣　　|
　　＼　　　　　　　 /
　　　 ＼　　　　 _ノ
　　　　/´　　 　 ｀＼
　　 　 |　　　　　　　|
　　 　 |　　　　　　　|

ファイルの日付が更新されてたら中身も更新されてると想定する文化ってあるらしいね
そういうとこではGit使うの無理だからアキラメロ

>>976
それで何か問題でも？
エディタでファイルを編集した場合も、
バージョン管理システムのcheckoutとかでファイルが変更された場合も
更新日時が新しくなる
そのソースファイルだけ変更されたとみなしてコンパイルすれば良い
makeなどのツールはそういう前提で動いている

ファイル中身の変更は管理する必要があるのはいいよね？
ファイルの日付が中身と同等と想定する文化では、ファイルの日付の変更も管理される

>>977
それが何か問題でも？って言われたら、
gitとmakeの併用が不便になるのが問題だとしか答えようが無いな

どうしてもってことなら post-checkout フックして
最終コミットの日付に設定しなおすスクリプトかませば？

他のバージョン管理システムもデフォルトのタイムスタンプの扱いは
同じだから運用見直すほうがマシだとは思う

>>978
「ファイルの日付が更新されてたら中身も更新されてると想定する文化」で許されないのは
日付更新なしの内容変更だろ？
内容変更なしの日付更新も許されないというのならその具体例は？makeじゃないよね。

makeはタイムスタンプが過去に戻ることなんて想定してないんだよ
gitのワークフローだと過去のコミットからファイルを引っ張り出すなんて日常茶飯事だぞ

タイムスタンプの話は総合スレでやれ。
誰か次スレよろしく。

>>980
日付更新なしの内容変更あり -> これはどんな場合でも当然許されない
日付更新なしの内容変更なし -> 何も更新されない正常な状態
日付更新ありの内容変更あり -> 正常にファイルが更新された状態
日付更新ありの内容変更なし -> 通常の文化圏ではこれを管理しないが、
上記の異常な文化圏ではこれを管理する必要がある

gitとmakeを併用する場合は「日付更新ありの内容変更なし」を
「日付更新なしの内容変更なし」と同じ扱いにする必要がある

「日付更新ありの内容変更なし」を管理する特殊な文化圏では、
gitの使用か、makeによるタイムスタンプ依存のビルドか、
どちらかをあきらめる必要がある

それが異常な文化圏ってのはいいが後段が意味不明。
結局その「異常な文化圏」って実際に存在するんだろうか？

昔、バージョン管理してないころ、変更手続き(書類のｗ)無しでソースファイルの更新日付変わってると大騒ぎしてたわｗ
バージョン管理導入したら、そんな習慣残すのは無理じゃないの？ｗ

コンパイルが必要なソースコードとは相性が悪いけど
タイムスタンプ保存の需要も、ないことはないみたいだ

Re: git check out file time
ttp://marc.info/?l=git&m=128118878725653

metastore
ttp://david.hardeman.nu/software.php

次スレ
Git 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/

>>983
>日付更新なしの内容変更あり -> これはどんな場合でも当然許されない

どんな場合でも、じゃなくて、それは「ファイルの日付が更新されてたら中身も
更新されてると想定」する場合だけだろ。
日付を内容更新の有無の推定に用いないなら当然許される。

上記異常な文化圏では「日付更新なしの内容変更あり」を想定したVCSが必要になるんだなｗ
そのせいでgit pull等した後にmake cleanが必要になるとｗ

想定したは正しくないな「日付更新なしの内容変更あり」を引き起こすVCSが必要になるとｗ

>>983
更新が無いのに日付だけが変わってしまう
ってのがそもそも問題だろ

>>991
実際に内容が更新されているいないに関係なく、
更新された可能性のあるファイルをワーキングツリー上に取り込んだときは
日付を常に最新にしないとmakeが動かないんだよ

ファイルの更新のチェックに日付を使うのが間違い
ファイルサイズで確認汁

ひょっとしておまいらの言っている「異常な文化圏」ってmakeのことか？

みんな、更新のチェックにはgit使おうぜ。

>>993
せめてチェックサム使おうぜ。

>>994
>>983の妄想で実在はしないだろ。
ファイルを変更して、その変更を元に戻した場合、日付も戻すべきなのか
進めるべきなのか一意に定まらん。