Git 13 [転載禁止]©2ch.net->画像>4枚

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

Git - Fast Version Control System
http://git-scm.com/

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

◆前スレ
Git 12
http://peace.2ch.net/test/read.cgi/tech/1427085313/

◆関連スレ
バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
CVS導入スレ〜 Rev.3
http://peace.2ch.net/test/read.cgi/tech/1113141518/
Subversion r15
http://peace.2ch.net/test/read.cgi/tech/1406967657/
【分散型バージョン管理】 Mercurial 2【hg】
http://peace.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://peace.2ch.net/test/read.cgi/tech/1356521407/
OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/

◆関連スレ 別板
CVS 1.3 [UNIX板]
http://peace.2ch.net/test/read.cgi/unix/1093611448/

乙

>>1乙乙

Git for Windows 2.5 正式リリース来た！

https://github.com/msysgit/msysgit 見ると
こう書いてあって
msysGit has been superseded by Git for Windows 2.x
https://git-for-windows.github.io/

git-for-windowsのレポジトリがこれで
https://github.com/git-for-windows/git

msysgitをforkしてmsys2で動くようにして
これからは本家msysgitに代わって最新版gitに追従するようメンテしてくれるようになったってことかね？

>>6
そう
だいぶ前にGit2系からgit-for-windowsが引き継いで
やっと正式リリースまでたどり着いた

周回遅れの話だな

>>8
追いついてこい。

gitを2.5にしたけど他の環境だとまだgit1.8のとこがあるけど1と2を混在して使って
何かまずいことってある？
コマンドの挙動に互換性がない変更が幾つかあるのは理解してるけど
リポジトリ自体のフォーマットは互換性があると思ってる

Git for Windows v2.5.0入れたらGit GUIが英語表示になっちゃったんだけど
どうやって日本語表示に戻すの？

インストーラー作った人がメッセージカタログを含めるのを忘れてるっぽい
誰かがバグレポあげてインストーラーを作り直してもらわないと直りそうに無いな

バグレポ出せるような人は、アプリの各種メッセージ等が英語でも気にしないんではないかと思ってしまふ。

そうは言っても英語圏の人はバグに気付いてないだろうから
誰かバグレポあげないとずっと直りそうにない・・

なるほど、インストーラー側の問題ですか。
誰かがIssueあげてくれるの待つかな・・・

あとgitkのブランチの色がすんげぇ暗くなったので
https://github.com/git-for-windows/git/issues/300#issuecomment-133484936
これを参考に#00ff00にした

いくらバグ報告にそってないからって、これを再現できないとか言っちゃうのはなんかなぁ・・・

>>15
そのIssueの画像のブランチの色は俺のモニターでも確かに暗くてつぶれしまって見えない
ただしそれは俺がモニターの設定をかなり暗めにしてるせいで
一般の人が設定してると思われる程度の明るさに設定すると暗すぎるって程の色じゃないと思うよ

>>14
つまりだ、困っている奴が、自分で出すのが一番早いんじゃないか？ということだと思うぞ。。。

ＧＵＩの日本語化とか要らなくね
英語のままのほうが日本語化できないソフトやツール使うときのメニューの意味とか分かるようになるし

Git 2.5がリリース，ワークツリーをサポート，三角形ワークフローやパフォーマンスなどを改善
作者： Sergio De Simone , 翻訳者 吉田 英人 投稿日 2015年8月19日
http://www.infoq.com/jp/news/2015/08/git-25-released

>>18
まあそうなんだけどさ、会社とかで使うときそういう本筋以外の部分で評価
下す馬鹿上司とかがいないわけでもない

Githubの話なんだけど、一度forkしてブランチ作ってPRしてマージされた後、
また本家のほうでいろいろコミットができたあとに、
また別の件でPRしたいとなったときって本家の新しいコミットを自分のforkに取り込むのって普通どうやるの？
前回のforkレポジトリを消してまたforkしなおせばできそうだけど、そういうもの？

>>21
以前にforkしたレポジトリのcloneがローカルに存在するなら
そこにオリジナルのmasterブランチをfetchして持ってきて
そのオリジナルのmasterブランチを元に新しいPR用のブランチを作って、PRするコミットを作成
そのPR用のブランチを、以前にforkしたGithub上のレポジトリにpush
Github上で、pushしたPR用ブランチからオリジナルのmasterに対してPR

こんな感じじゃないの？

>>21
マージされたブランチは、通常すぐに消すものだよ。
forkしたリポジトリは消さなくていい。
最新に更新するだけ。

つまりマージされたブランチは削除してないものとして考えると、
単に「あなたのリポジトリは本家に比べて古い。」というだけ。

だから最新にしたいブランチ（通常はmaster）を
git pullして最新にすればいい。forkした自分のmasterを
更新とか変なことをしていなければFast Fowardで最新に更新される。
そこから新しくブランチを作ればいい。


ちなみに、一度forkしてブランチ作ってPRしてマージ"されたなかった"後に
本家でコミットが出来た場合、自分のブランチをrebaseして
最新のmasterから修正した形に歴史を書き換える。

>>22 >>23
ありがとう。
22の方法が普通っぽいのかな。
23のgit pullはどこで（Github上で/ローカルで）実行するといっているの？Github上でできる？

>>22はどんな状況からでもレポジトリそのままで新しいPR用ブランチが作れればいいって感じで書いた
オリジナルのmasterをpullしなくてもfetchだけで(つまり自分のmasterは汚い状況)PR用のブランチは作れる

でも>>23が書いてるようにforkした自分のレポジトリのmasterを元のレポジトリのmasterと同期させるのが
公式おすすめのやり方みたいだよ

https://help.github.com/categories/collaborating/ の Syncing a fork とかを読んでみて

Makefileやbuild.xmlとかVisual StudioなどのIDEが自動生成・編集するようなソースコード以外のファイルもgitで管理したほうがよいの？
直接編集が難しそうなIDEが生成したファイルとかがコンフリクト起こしたらどう対処してるの？

【背景】
ローカルに clone してある物が既に古くなっているか否かコマンドライン上で確認したい。

今迄開発の現場で Gui 経由でしか Git を使用した事がありません。
今回自動テストで使用する為にバッチファイルを作成する必要があります。

【質問】
どの様なコマンドで確認すればいいのでしょうか？

詳しい方、どうぞ宜しくお願いします。

git branch

>>27
ローカルにcloneしてそれを編集しないって前提なら
クローン元の名前がoriginでそのブランチがmasterだとすると

まず git fetch して
git rev-parse remotes/origin/master で表示されるハッシュと
git rev-parse HEAD で表示されるハッシュを比べて
同じなら最新

>>26
.gitignoreで除外する
IDEが糞だったりレポジトリ作った奴が馬鹿だとうまく運用できないときがあるから
そういうときは git update-index とか使う

>>29
詳しい説明、どうもありがとうございます。

お察しの通り、自動テストなので clone側はコードに一切手を加えません。

近日中にご教示下さった様に試行してみます。

# CI も初めてだし、この件も初めてだし、
# こんな事を(その道の)素人にさせる現場も理解し難い。

>>29
出来ました、ありがとうございます。

目視確認なら fetch した後で status で教えてくれる
もしくは log master..origin/master とか

初心者です。
疑問があります。

ブランチ００１を作成。
マスターから００１にブランチを切り替えた後、適当にファイルを編集して、
add,commitしない状態で、マスターブランチに戻るとファイルの内容が変更されてしまいます。


００１で編集後に、コミットするとこういった現象がおきません。
これっておかしいと思うんですが理由があるのでしょうか？

>>34
ファイルを編集するワーキングツリーはブランチ毎に用意されているわけじゃないってことだよ

でもそれだとファイル編集したらブランチ移動がまったくできなくなっちゃうので、
条件付でブランチ移動ができるようになっている

その条件は編集したファイルが移動元と移動先のブランチで同一であること

慣れればこの挙動は便利

>>30
.gitignoreで除外して支障はないの？

>>36
Makefileやbuild.xmlのような情報をユーザが編集できない形式で保存してるIDEは滅べばいいんだよ

slnやvcxprojなら普通にgitで管理するな。
コンフリクトしたときの処理は注意が必要だけど、まぁフォーマットを理解すれば問題ない。

vcxprojとかしょっちゅう手作業でいじってるな…ほんとは良くないのかもしれんが
でもバージョン管理してれば間違っても安心だ

masterでコミットした内容を開発ブランチに取り入れる場合
git rebase master

開発ブランチをmasterに統合する場合
git rebase 開発ブランチ

これであってますか？

普通はmasterブランチをリベースしません

ここにmasterにrebaseしてたので
http://qiita.com/bibio/items/209016b722f550ae4088

>>42
じゃあ、その逆もその記事を参考にすればいい。

>>42
＞masterでコミットした内容を開発ブランチに取り入れる場合
＞git rebase master
これはたぶんカレントブランチが開発ブランチの状態で行うつもりだと思うので、
リベースするのは開発ブランチです

＞開発ブランチをmasterに統合する場合
＞git rebase 開発ブランチ
これはたぶんカレントブランチがmasterブランチの状態で行うつもりだと思うので、
リベースするのはmasterブランチです

普通はmasterブランチをリベースしません

>>42
もしかしてカレントブランチという概念を理解していないのですか？
git rebase はカレントブランチをリベースするコマンドです
カレントブランチをどこを起点にしてリベースするかを引数で指定します

ああ、カレントブランチをリベースするのは
ブランチもしくはコミットをひとつだけ指定したときね

gitで、ある任意の行が いつ更新されたのかを知るにはどうしたらいいの？

cvswebでいうところの annotated みたいな感じのやつ

blame?

>>48
ありがとう、それだったわ
日付出ないのが不便だけど無いよりはマシっぽい

gitも早くcvs並みに使い勝手が良くなるよう応援するわ

git blameで日付出るよ。
煽ってるつもりなんだろうけど、
こちらは煽るつもりもなく
gitはcvs以上の事をすべて行えるって
事実を言っておくねｗ

gitwebでソースの改変ログを見る時
shortlog に表示されてるログがやたらと古いのしかないんだけどなんで？
tagsにはちゃんと最近の分が表示されてるけど

>>50
古いバージョンだと出ないとか？

pullで更新を取得したときだけbuildしたいんですけど
なんか方法を教えてください

2.5以降のWindows版のgit-guiが日本語化されないのはインストーラーのサイズを
小さくしたい為に意図的にメッセージカタログを含めてないんだってさ
インストーラーは現状30MBほどあるけど1MB増えるのが許せないらしい…

gitだけに限らんけど
もう言語ファイルは全て含めたほうがいいと思う。

自分でコンパイルすればいいだろ
余計な言語ファイルなんていらねえよいらねえよ

言語ファイルは余計じゃない

英語が出来ないがこの業界で余計な存在

翻訳ファイルが用意されているのに自分でビルドもせず文句垂れてる奴はクズ
これだからWindowsユーザーは低能が多いんだよ

英語は出来るが言語ファイルは余計じゃない

>>58
自己紹介乙ｗ

翻訳した人の苦労も考えずにたった1MBの容量をケチって独断で
インストーラーから外した奴の擁護する奴の気が知れない

Git GUI使ってる人はなんでSourceTreeを使わないの？

自分ビルドできないの？
ひょっとしてバイナリ配布を当たり前のように思ってるの？

>>64
そりゃそうだろ
なんで俺がビルドしなきゃならないんだ？
そんなのはお前らの仕事だろ？

Linux上だと色々自前でビルドしてるがWindows上でビルドなんて暇人のやる事だ
自前でビルドなんて誰でも出来る事をドヤ顔で自慢するスレに成り下がったか…

自分が一切関わってないコード群のビルドなんて正直やりたくないな
BSD系のOSはアプリをいちいち全部自分でビルドしなきゃいけないっていうし大変そうだな

ちなみにWindowsでビルドするにはMSYS2を入れるだけで良さそうだけど
Windows上で動かすgccは異常に遅い。多分10倍ぐらい時間が掛かる
(別にgccが悪いわけじゃない。Linux上だと普通に速いから)
でかいアプリのコンパイルを始めるとマジでブチ切れそうになる

Linuxならビルド環境整えてgitをソースから構築とかするの簡単だが
Windowsだとわけがわからんな
http://msys2.github.io/ から msys2-x86_64-20150512.exe をもってきてインストールして
pacman -S base-devel はできたが
pacman -S mingw-w64-x86_64 これが404で全部失敗する
ここはWindowsでのビルド楽勝な人が多いみたいだから失敗の理由とか即わかるよね？教えてくれない？

gccが遅いならclangでためせば

>>69
答えを探せない奴は向いてないからGitを使わないほうがいいよ

とりあえずオプション追加して404が出なくなるが
こんなエラーがでてインストール失敗
texinfo-tex: /usr/bin/texindex exists in filesystem
これも無効にするオプションを指定して進むようになる
しかしこんどはインストール進行中にこんなエラーがでまくる
error: could not fork a new process (Resource temporarily unavailable)
初期のBSDやLinuxだってこんなひどくは無かったな

>>71
答えはとっくに出ている
いちいちソースから構築するのは阿呆

オプション→更新履歴の表示→詳細で開くリリースノートのページが
ちゃんと日本語版が表示されるようになったな
Mozilla Japanグッドジョブだ
後はMozilla Japan ブログのRSSが壊れててブックマークメニューから
読み込めないのを修正してくれ

すまん誤爆した

IDとパスワードを入力するuser.phpがあります
<?php
$id = "";
$pass = "";

この状態でコミットしました。
これ以降の編集では実際のIDとパスワードを入力するので、このファイルをコミットしたくないんですが
どうやるのかおしえてください

訂正

これ以降の編集では実際のIDとパスワードを入力するので、このファイルをコミットしたくないんですが
↓
これ以降の編集では実際のIDとパスワードを入力するので、このファイルを今後コミットしたくないんですが

>>76
そのファイルをコミットしないでください。

>>76
本来はGitで管理しないファイルからidやpasswdを取り込むような仕組みにするべきだけど
どうしてもGitで管理するファイルにそのまま書きたいなら
git update-index --skip-worktree でファイルの修正をgitから無視されるようにする

今までgit cloneでダウンロードするだけだったgit初心者ですが、
とあるOSSで見つけたバグを報告するため初めてアカウントを作り、
http://blog.mogmet.com/github-abecedarian-send-pull-request/
などを見ながらプルリクエストをしました。
これから色々勉強していくつもりですが、一つだけくだらない質問をさせてください。

githubで公開されてるリポジトリというのは基本的に誰しもが開発に参加できるという思想だと思いますが、
それは建前で実際はケースバイケースだったりするんでしょうか？

例えば、いきなり第三者がフォークしたりプルしたりすると、元からいる人たちが
「誰こいつ？」とか「素人は引っ込んでろ」みたいに冷たくあしらわれて
拒否されたりBanされたりすることはあるんでしょうか？

>>80
プルリクはrejectあるいは放置される場合もあるが、誰こいつとはならない。
ただ、あまりにうざい振る舞いをすると、blockされてしまうこともある。

>>80
ブログとかslackで陰口言われてますよ

>例えば、いきなり第三者がフォークしたりプルしたりすると、元からいる人たちが
>「誰こいつ？」とか「素人は引っ込んでろ」みたいに冷たくあしらわれて
>拒否されたりBanされたりすることはあるんでしょうか？

閉鎖コミュニティーが好きな日本人ぽい発想だね
それだったら公開リポジトリにする意味が全くないし
外国語分からなくたって機械翻訳で必死にコミュニケーション取りながら進めたりするんだぜ

慣習や空気みたいなものがあって、そういうのを理解しないと
まずいのかなと思ったりしたのですが、考えすぎですかね？
使うだけだった人間から少しずつ開発に貢献する人間になろうと思います。

Githubで公開していても、Githubのプルリクでのパッチは受け付けない方針のところもあるけど(Linuxカーネルとかそうだっけ？)、
基本はちゃんとコミットが整理された形で、しっかり説明がついたプルリクが来たら対応してくれるんじゃないだろうか。

Issueを作ってどういうバグか説明してからIssueにひも付けでプルリクしたほうがわかりやすいような気もするけれども

管理者から「masterはstableブランチなので直接の変更は駄目」と返事があり、コミットがクローズされました。
代わりにその人がdevelopというブランチにコミットしてくれていました。

今まで初心者用サイトをググった限りプルリクエスト先はmasterにしているものばかりでしたが、
実際にどのブランチにプルリクエストをするかはリポジトリ毎に様々なんでしょうか？
今回の場合、developブランチにやれという記述はgithubページのどこにも見当たりませんでしたが・・・

Git FlowやGitHub FlowといったメジャーなGitの運用法を用いてる場合が一般的
そしてたいていの運用法ではmasterブランチにプルリクエストは送らない
あとGitHubとGitを混同しすぎ
GitHubはGitを使いやすくするための１ツールであり１サービスである

Gitの質問ではなくGitHubの質問ならスレとしては↓のスレが適当

OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/

>>86
自分のリポジトリにforkしたあと、ブランチを切ったかね？
それと勘違いしている気がするが。

>>86
不採用になってもしつこく送れば取り入れてもらえません
諦めずにmasterに送り続ければきっと管理者も心を開くでしょう

Git FlowやGitHub Flowって一般的っていうほど普及してるかな。
いまのところPR先で出会ったことない。

githubにプロジェクトを登録しましたが、誰かがクローンしたかどうかというのはわかるもんなんでしょうか。

>>91
ここはGitに関するスレなのでホスティング固有の質問は専用スレへどうぞ

gitにプロジェクトを登録しましたが、誰かがクローンしたかどうかというのはわかるもんなんでしょうか。

Git 2.6 Release
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.6.0.txt

>>94
日本語訳ちょうだい

ろくでなし 2.6 釈放
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.6.0.txt

「Git 2.6」リリース
https://osdn.jp/magazine/15/10/01/065200

もはや更新内容がマニアック過ぎてほとんど意味が分からん

こんな機能追加が許されるのは、プログラマ向けだからだよなｗ
誰がどんな時に使うのかけわからん機能ばっかりだ。

プログラマ向けと言うか基本的な機能は完成されてるから
細かい機能追加になりがちなんだろうね
ただ最近はコマンドを直で使わなくなってるから尚更機能追加が実感しにくい

Gitて現実の世界で役に立つの？

>>101
現実じゃないどこの世界で使ってんの？

一体どの世界線だ

ワイヤードの住人なんだよ

今後も、このスピードで細かい機能をどんどん追加していくのかな？
それとも、別途大きな機能を作ってるのかな？

この調子で行くと3.0で全く新しくなって完全に互換性がなくなるんじゃないかな？

git logにreflogを取り込むべき
git log --reflogのようにね
無駄にコマンド分け過ぎなんだよ

まとめてしまえばいいと思うコマンドはあるが、logとreflogはないわｗ

>>106
どんな調子だ？gitは1.xのころから互換性無くなるような修正ほとんどしてないぞ

受ける会社大丈夫？
下記の条件が全て当てはまる会社にご注意下さい。

・IT系 in tokyo
・「社名　労基」でググると過去の2chスレが出てくる
・転職会議で2.5点

そろそろgit専用のスクリプト言語を作るべき

ただのコマンドなんだからシェルスクリプトで十分でしょ

git専用スクリプト言語がてき、そしてCで再実装されるのだ
永遠に

.gitignoreと同じような処理をシェルスクリプトだけでやりたいんだが、
これ、ただのglobじゃねーよな？難しいんだろうか？

hookの書き方がわかりません

>>115
それは大変でおじゃるな

gitって、ここ10年でのソフトウェア開発での目覚ましい革新の一つだと思う。
ビルドシステムもなんとかならんのかな。
makeの次が何なのか。makeの次もmakeなのか。
ant、mavenはjava寄りだし、なにより緻密すぎ。
gradleは緩いけどやはりjava寄り。

>>117
別にgitが革新を起こしたとは思えない
似たようなものは前からあったわけだし
ビルドシステムも山ほどあるけどオープンソースにはcmakeが人気ある
でもやっぱりautotoolsでしょ

p4参考にしたのかもしれんけど、コードとしてはゼロから始まって、
cvsはもちろん、svn, hg駆逐して、githubその他サービスも派生して、
単なるツールからインフラになったわけよ。
svn, hgでgithub的な事ができるかというと出来ない。

>>119
ホスティングサイトはsourceforge.orgが長い事使われてたじゃん
一応csvとかsvnと連携してたと思うけど

間違えたsourceforge.netだったか

csv→cvsもだった…ごめんちゃい

個人で使うならRCSで充分

>>123
それだけは絶対にない

>>124
いや普通に有りでしょ
管理するものによる
サーバーの設定ファイルとかrcsで十分

>>125
いや、わざわざ使い分けてまでrcsを選択する理由がないってこと。
むしろgitだけあれば十分。

svnに戻りたい

>>126
じゃあRCSで十分でいいよ

svnとかhgとかわからないので出来ればこの辺のツールの仕様を標準化してもらいたい

hgはともかくsvnを知らないのは明らかに無知で中二だよな

>>128
なんでわざわざRCS
アホか

>>131
それで十分だから

あ、ごめん
触っちゃいけない人だったか
git使ったことがない人なのかな

もしかして: 老害

サーバーの設定ファイルの管理だと、部分的にチェックアウトできないgitは
ちょっと使いにくそうだな。せめてsvn。

>部分的にチェックアウトできないgit

こマ？

gitもRCSも両方使ってる
老害とかネットスラングを使う奴はネットやり過ぎで脳みそが萎縮してる証拠

RCSって何？と思ってググったら
こんなのが未だに現役なのかよｗ

https://ja.wikipedia.org/wiki/Revision_Control_System
初版 1982年（33年前）
最新版 5.9.1 / 2013年10月4日

英語版wikiのほう見たらRCSの最新版は2015年1月22日とかバリバリ現役すぎて吹くｗ
33年前の遺物を未だにメンテしながら使っているのかｗ

単にお前らが無知なだけだろ

RCSの手軽さは上司から耳タコなんだけど、ぶっちゃけgit慣れた今どきに手軽さとか言われてもよくわからんってのが本音。
俺も30過ぎのおっさんだから世代ギャップとかあんま言いたくないけどさ

なんかgit以上の利点とかあったら煽りでなく教えて欲しいな。
SVNやVSS通してサーバ型しか知らん人間も多いんでない？
今時の経験薄い新人とかgit以外は過去の遺物扱いだしさ、いっちょ語ってくれよ

時代についてけないおっさんは旧製品といっしょにまとめて捨てられるんやで

一つのファイルをバージョン管理するために、
一つのrcsファイルを作成するだけでいいってのが最大の利点じゃない？

>>143
うーん。実装がシンプルなのは良いよ。それを百も承知で聞くけど、それ今時のシステムで利点となってるかなぁ？
こちらの疑問をまとめると、「gitでだめなの？」「gitの運用はシンプルじゃないの？」って話になるのかな。

っとすみません、賑やかし目的な話題提案に過ぎないので、スルーで構いませんです。
何かのついでで、興味ある方のご意見を拝聴できれば幸いです。

gitはos標準で入ってなくてもRCSは入ってたりするからな
開発環境はともかく運用環境にgitが入ってる必然性はないから
設定ファイルなんかのバージョン管理ではバリバリ現役

あくまでもweb界隈以外の話ね
環境使い捨てるとか言ってる人たちには縁ないかも

>>145
環境使い捨てるの意味わかってないんじゃない？ｗ

環境をコードで記述するから、仮に捨てても
同じ環境がすぐに手に入るって意味だよ。

それに対して、従来は人がコツコツと作っていたから
環境を作るのに時間がかかっていたし、壊れたり新しく作る時の
再構築が大変だった。

>>145
で、RCSだけど、今のOSには入ってないよ。

きっとあんたのところ、環境が古すぎて
アップデート出来てないんじゃね？
環境が秘伝のタレとかして捨てるに捨てられない状況になってそう。

10年以上同じ環境をろくにアップデートせずに使い続ける人たちにGitは必要ないから巣に戻りなさい

>>145
運用環境にgitが入ってないというけれど、
git含めたバージョン管理ツールは開発ツールなのだから、
運用環境にはgitもsvnもrcsも要らなくね？

デプロイは他のマシンから操作して
ソースコード（もしくはバイナリ）を配置すればいいわけだし。

運用環境＝実機サーバーに直接ログインして
設定書き換えます。バックアップとして前のファイルを
とっておきましょう。って話？
rcsってファイル単位だし、開発には使えないよね。
なるほど、だから設定ファイル専用なわけか。

>>144
お前シンプルなのが利点て認めてんじゃん
それを承知で駄目なの？駄目なの？聞いてる時点で老害より脳みそが凝り固まってる無能じゃんｗ
目の前に小型ナイフがあるのに一生懸命アーミーナイフ(十得ナイフ)で肉切ろうとしてる奴に似てる
(現実にあった)

実装より使うときのシンプルさに意味があるの
運用環境のファイルいじるときに念のため.bakとかつけてオリジナルを残す感じでrcsファイルを残しておける
rcsファイルは別の環境で作ってもいいから、その運用環境にRCSがインストールされてなくてもいいんだよね

バージョン管理の基本的な仕組みはRCSに全部実装されてる
(基本的な仕組みのみ実装されてるとも言える)
最近のOSって何を言ってるのか不明だがサーバー向けLinuxには必ず入ってる
それを考慮すれば設定ファイルを管理するには最適だ

つうかRCSなんて目茶シンプルなツールで使い方も超簡単なのに
自分が知らないってだけでこんな必死に反論するのが滑稽だな
そんな必死に反論するようなツールじゃないよ

>>151
> rcsファイルは別の環境で作ってもいいから、その運用環境にRCSがインストールされてなくてもいいんだよね
それはgitでも一緒では？

>>152
> バージョン管理の基本的な仕組みはRCSに全部実装されてる

何を基本的なと言ってるのかしらないが、
今の時代では、バージョン管理システムは
複数のファイルを1コミットで扱えないと駄目だし
リモートへのpush、pullもサポートしていなければならない。

RCSにはそれがないので、今の時代に求められる
基本的な仕組みを実装できていない。

ぼくのかんがえたきほんてきなしくみ

Linuxサーバーでも今時はGUIでファイルのコピーとか出来るけど
それでもちゃんとcpとかmvとか最低限のコマンドは覚えるでしょ
RCSもその程度のもんだ

>>152
> 最近のOSって何を言ってるのか不明だがサーバー向けLinuxには必ず入ってる

入っていない。

実際にUbuntu、Debianに入っていなかった。

過去は使われていたかもしれないが、
今はお役御免になって証拠だよ。

もうこれから使いませんって宣言されてるものを
使う必要はない。

>>156
今のLinuxに標準的にインストールされていないものは
cpやmvとぜんぜん同等じゃないよｗ

>>154
お前頭悪いな…プログラマじゃないだろ
バージョン管理の基本的な仕組みって分かってる？
じゃあRCSで設定ファイルが管理出来ないって事か？出来てるよね？それはなんで？

>>157
CentOSとか入ってるよ

>>159
> じゃあRCSで設定ファイルが管理出来ないって事か？出来てるよね？それはなんで？

お前こそプログラマじゃないだろｗ

設定ファイルの管理とソースコードのバージョン管理はぜんぜん違う。

ソースコードのバージョンというのは、機能の差分ってことだ。
機能っていうのは通常複数のファイルの同時修正から成り立ってるから、
複数のファイルを同時に管理できないと駄目。

これは必須の機能。

単一のファイルのバックアップだけでいい設定ファイルとは
扱い方がぜんぜん違う。

>>160
CentOSにも入ってないよ。

yumで別途インストールしないといけない。

必ず入ってるというサーバー向けLinuxが何を指してるのか不明なんだが
そんなに便利ならなんでLinux系の技術サイトに設定ファイルのバックアップにRCSを使ってるところがまるで見当たらないんだ

>>160
目の前のCentOSのターミナル叩いてみたけど入ってなかったぞ
バージョンいくつだよ最小構成以外で入れてるのか？

あと、サーバーの設定管理であれば、
etckeeperを使って半自動で管理するのが多いと思うが、

rcsは対応してないようだね。

# The VCS to use.
#VCS="hg"
VCS="git"
#VCS="bzr"
#VCS="darcs"

>>153
たとえば、新規にRCSで管理したいと思ったときは、
修正するファイルをRCSがインストールされてる環境にコピーしてきて
rcsファイル作成、ファイル修正、rcsファイルにコミット、rcsファイルと修正したファイルを元の環境にコピー
これでとりあえずいいわけよ
更新する場合にはrcsファイルをコピーしてきておなじようなことをやればいい

おなじことをgitでやろうと思えばできるけど、
コピーするファイルとかディレクトリが増えるだけでgitのメリット何も生かせないし馬鹿みたいだよ

>>161
お前日本語読めないのか？
設定ファイルが管理出来てるならバージョン管理出来てんだろ
誰も機能の管理なんて言ってねーよ

そもそも複数のファイルが同時にコミット出来れば機能の管理が出来てると
思ってるお前の脳みそもお目でてーな
複数のファイルがコミット出来るのは複数のファイルに同じバージョンを
振れるってだけで機能の管理とは当然のことながら無関係だ

>>165
> たとえば、新規にRCSで管理したいと思ったときは、
> 修正するファイルをRCSがインストールされてる環境にコピーしてきて
> rcsファイル作成、ファイル修正、rcsファイルにコミット、rcsファイルと修正したファイルを元の環境にコピー

それ、大変って言わね？ｗ


gitに比べて何が簡単なのか、全く同じじゃねーかｗ

>>166
> 設定ファイルが管理出来てるならバージョン管理出来てんだろ

だからお前の言うバージョン管理が、
単なるファイルのバージョン管理でしか無いんだって。

今求められるのは、そんなバックアップに毛が生えたような機能じゃなくて、
アプリの機能のバージョンの違い＝複数のファイルの修正の管理が
できるツールなんだって。

それが出来ない時点で、RCSはバージョン管理ツールの目的を満たせない
劣ったツールなんだよ。設定ファイル管理ツールと言い直すべきだ。

>>162
CentOS6.4だが…じゃあ開発ツールをインストールする時に入ったのかよ
単純なサーバー向けインストールじゃ入らないんだろうね

>>168
今求められるってなんだよ
本質的な機能のバージョン管理の話しをしてんだよ
そういう概念的な話しをネチネチするのが文系だって言ってんだよ

RCSは複数のファイル管理には向いてないよね、で終わりだろ (当然不可能ではない)

>>167
同じことをgitでどうやるか考えてみろよ
gitでやるメリットが何もない上に余分なファイルが大量に必要になるんだぜ？

>>169
秘伝のタレじゃねえかｗｗｗ
何年やってるか知らんが経験が狭すぎて素人同然だな

>>172
秘伝のタレって何？
仕事なんだから環境構築は俺じゃない奴がやってるから詳細なんて知らないよ

>>147
FreeBSD 10.2でman coしたら出てきたし
OpenBSD 5.8でman coしても出てくるよ

>>173
> 秘伝のタレって何？

以下参照。インフラ関連の文脈ではよく使われる。
http://itpro.nikkeibp.co.jp/atclact/active/14/011400148/

なお、>>169は秘伝のたれではない。

>>151
おれetckeeper使ってる
超便利
etckeeperのバックエンドは標準でgitになってるなCentOS7の場合

俺なんかrcsで作られてる差分管理ファイルを自分のPCのgitで監理してるぜ

個人ならいいけど業務で設定をダイレクトに編集するのは悪い運用体制だから業務でetckeeperは使わないほうがいい

>>178
おお、説明不足すまん
テスト環境上でetckeeperで管理している設定ファイルを、
設定が固まったあとで本番環境に持って行ってる

本番環境からテスト環境へのファイルコピーはやってない(設定ファイルの場合ね)

>>178
yum等でアップデートされた時も自動で管理してくれるから、etckeeper使うメリットあるよ

>>174
卑猥なシステムだな。

Git 2.6登場、多数の新機能と改善
作者： Sergio De Simone , 翻訳者 笹井 崇司 投稿日 2015年10月14日
http://www.infoq.com/jp/news/2015/10/git-26-released

意地張ってWin版インストーラに翻訳メッセージ含めてなかったのが遂に折れたか
ただ将来インターナショナル版インストーラを作る時用って言ってるからまだ暫く含まれる事は無い

gitに限らず翻訳メッセージを含めないっていうのは
今はありえないと思うわ。

せめて自動取得するようにするべきだろうね。

翻訳なんていらない

>>185
別に英語まま使う事は簡単に出来るんだから英語で十分アピールはいらないから

で、この後自分でビルド出来るアピールが続くんだろ

GUIとマニュアルを除けばgitのビルドは簡単だよ。

だからそんな事分かってるっての

英語が出来ないｇｍｋｚに世界のエンジニア達が合わせる必要はない

>>190
英語出来るらしいけどTOEIC何点ぐらい？
まさかgitkのメニューが分かる程度で英語出来るって言ってないよね？

ジャンル限らず和訳の話が出たあとはだいたいこういう流れになるなぁ

git使うのにTOEICの点数何点くらい必要なの？

エラーメッセージでググるとき面倒だから英語でいいや

>>193
300点もあれば十分

まあ真面目に考えて、日本以外の国で、git使うようなエンジニアorアカデミック層で、gitのメッセージレベルの英語が理解できなくて困る人っているのかという疑問はある

まあgitのメッセージレベルの英語は理解できなくても困らんよな

>>196
困ることはないが、母国語の方が余計なこと考えなくて済むから気持ちがいい、
と考えるエンジニアなどが日本以外にいても不思議はないと思う。

むしろアプデして日本語になったら英語に戻す

みんな俺英語読めるを言いたくてしょうがないんだな…
自分しか英語読めないと思ってんのか、一々反応する奴はマジでウゼーよ

取り合えず翻訳メッセージはgit公式ツリーに含まれてるちゃんとした成果物なんだよ
それを含めるのは当然の事だ
ポリシーの問題で英語読める読めないを言ってんじゃねーんだよ

読める読めないじゃなくて相互運用性を優先してんだよ
チームで情報共有や周知するときに複数言語混ざってたらプチバベルの塔だわ

ズれてんだよな単に

>>201
また概念的な事をネチネチと…しかもズレてるし

>>203
オメーが一番ウゼーよ…しかもズラズレてるし

翻訳くれくれ厨まじで気持ち悪いな
そんなに欲しいならissueで議論してくればいいのに
それすらできないなら文句を言う資格なし

>>205
issueに書き込んで速攻重複だとcloseされたからそのissueを見てみたら
1MBインストーラのサイズが増えるから削除した(βの段階ではあった)と書いてあった
しかしその時点でインストーラのサイズは30MBほどあったが

ちなみに翻訳メッセージが含まれてないというissueは他にも幾つかあった
もちろん日本人ではない

そんな経緯があったからたまにインストーラのcommitログを見るようにしてんだろ

とりあえず俺は文句言う資格はありそうだなｗ
ちなみに最初の翻訳メッセージの書き込みから英語うんぬんで反応してる奴は
全員低能だから
まともな奴はふーんで終わりの話題

俺はいらないをインストーラに入れるなに脳内変換してるお前が低能というか精神病
開発に関係ない2chでコンセンサス求めてる時点で相当の馬鹿
MLで相手されないからってこっちくんな

公式で受けいれられなくて2ちゃんでうだうだ言ってるやつは基本ウザい
つーかウザいから公式でも話を聞いてもらえない

>>207
何度も書いてるが、gitのソースツリーに含まれてる成果物なのにインストーラ
作る奴の独断で含めないのはそいつのポリシーを疑うと書いてるだけだ
(スレをちゃんと読めば分かる)

そういうポリシー的な事には一切触れず翻訳ってだけで脊髄反射していらないといってるから
アホだなと思って相手してるだけだよ (必要以上に煽ったのは認める)

翻訳メッセージの状況が変わったからとりあえず>>183を書き込んだが
その後でまた翻訳イラネ厨が湧くだろうなと思ってたらやっぱりそうだった
そいつに対して必要以上に煽ってしまったのは認める

>>206
そこで訴えてない限りお前に文句を言う権利華

翻訳ください野郎は>>69、>>72みたいにあ自分でビルドもできないおぼっちゃま君だろ
逆ギレしてるのに教えてもらえるのを期待して書き込んでるのがウケルｗｗｗｗ

>>211
訴えるってなんだよｗｗｗgithubは裁判じゃねーよｗｗｗ
つうかお前issue読んでないだろ英語出来ないの？ｗｗｗ

>>212
出た！ビルド出来るアピール！
autoconf && ./configure && make
でバカでも出来るのにわざわざアピールする低能ぶり

しかいこのスレはよく釣れるなｗ
gitスレがこんな低能が集うスレとは思わなかった、入れ食いだもんなｗ

ID:8pAifeJvはゆとり

>>215
んなわけないだろｗ
おっさんだよ

じゃあ、ゆとりのおっさん

>>217
じゃあそれでいいよｗ

馬鹿だから気づいてないようだがお前は馬鹿で低能な精神病のラベルが貼られてフィニッシュしてるんだよ
馬鹿で低能な精神病として嘲笑を浴びた引き換えに釣りができてよかったね(笑)

>>219
反論するなら具体的に言ってよｗ
そういうこといってるから低能なのをさらけ出してるって言うんだよｗ

gitスレってこんな奴ばっかりｗｗｗ

・ビルドを自動化すればいいのに手間でもないんだから自分でビルドしろ
・issueで何故必要なのかを強く訴えられないなら黙った使うか別ツールを使え

以上

>>222
お前反論するならちゃんとスレ読め
ビルド自慢じゃなくてポリシーの問題だ
Issueで訴えたからインストーラに含まれる予定になっただろ
こうやってトンチキで意味不明なバカ丸出しのレスをするのがgitスレなんだよな

Win版インストーラに翻訳メッセージが含まれるかもって言ったら
そんなの要らね―って脊髄反射する奴多数
gitスレってこんな奴ばっかりｗｗｗ

>>222
お前ちょっと見れば分かるようなissueすら読めないんだなｗｗｗ
反論するなら英語読めるようになってくれよｗｗｗ

どこにそんなissueがあるの？

>>214
ほんと定番化してユーザー増えたんだなーって実感するね
「分散とか意味わからん」だの「SVNと比べて使いにくいわボケ」とかそういう比較で荒れてた時代が懐かしい

ほんとそうだな
翻訳ファイルが同梱されなくなっただけで発狂するバカが湧き始めちゃったしな
まったく変な奴が住み着いちゃったな

>>228
発狂って何だよ
俺は翻訳が―って言ってる奴を面白いから煽ってるだけだ
それはスレを読めば分かる
当然お前も翻訳が―の同類だがな

最初に>>183で翻訳が含まれそうだと言ったらお前らが発狂し始めたんだろうがｗｗｗ

常用してる言語に比べて、英語っていうのは読めても理解の速度が遅いから
この「理解の速度」って読めるかどうかの問題じゃなくてですね
例えば日本語で書かれてる技術書だったら1時間もあれば読破出来るとしても
英語だったら何日もかかるだろう

常用してる言語が日本語なのに、わざわざ英語を読むっていうのは
そんだけエネルギーを消費し、それだけ頭に汗をかくということで
ハゲに繋がる

つまり>>1はハゲ

>>226
おれもみつけきれんかった

issueを探す能力が足りないだけ。
すぐに諦めないで、いっしゅう間ぐらい探せ！

そんなーケチ
一蹴しないでリンク張ってクレヨン

ちなみにgitにはissueはないよpull requestのみ。
どこのissueを言ってるのか提示しないと

このスレの前の方から辿らないとわからないかもしれないが、
翻訳メッセージがどうこうはGit本家の話ではなくて git-for-windows の話
Githubのレポジトリは >>6 参考ね

中卒、高卒の低学歴は許せても、英語の読めないバカだけは許せない

英語が読めるだけの馬鹿は許せるの？

中卒許せるって言うんならそういうことでは。

>>239
お前はどうなのって質問だろ？

インストーラーでインストールした後に言語ファイルを追加する方法はないの？

>>241
マニュアルとライセンスを英語のまま読めば、そんなものは問題にすらならない

>>242
何その的外れな返答

インクリメントされていくバージョン番号が欲しいなぁ

>>244
3.14
3.141
3.1415
...
みたいなやつ？

>>245
そんなん出来たらクヌース大喜びだなｗ

0が出てきたときの扱いが気になるところ

プッシュされたらなにかする
というスクリプトは書ける？

post-receiveフック

>>242
自分はMacでもLinuxでもgitをコマンドラインで使ってるし、manも英語で困らないんだが、単に純粋な疑問として、
インストーラーから削られただけだったら別の方法で日本語関係のファイル入れられるんじゃないの？と思って聞いたんだけど。出来ないってこと？

>>250
git-guiやgitkはgettextの仕組みでメッセージのローカライズをしてるから
*.poファイルをコンバートしたものを然るべき場所に置けばできるはず
昔のWindows版gitをインストール後それをコピって同じ場所に置くのが一番早いかも

>>249
ありがとう
ここでバージョン番号つければいいんやね

>>251
正解。ちなみにUbuntuでは（おそらく）公式とは無関係に独自で日本語化している。
gitコマンドの出力が一部日本語化されているのですよ。

>>251
ありがとう。だったら、日本語化関連で文句を言っている人は単にその手順をまとめてwikiにでも書いて広めればいいよね。
自前ビルドとかする必要もないし、日本語化されるし、installer作ってる人を説得する手間も無いし、とりあえずの解決策としてはベストと思うんだが。
日本語化が要る、要らないは人によって違うだろうし、そこでどうでもいい宗教論争しても全くしょうがないと思うけど…

git pull --depth 1ってしたら
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
You have unmerged paths.
(fix conflicts and run "git commit")

ってなったんですがこれはどうしたらいいのか教えてください

git commit したら
error: commit is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
ってでました

Gitのコミットメッセージの書き方 | プログラミング | POSTD
http://postd.cc/how-to-write-a-git-commit-message/

>>255
なんのために--depth 1とかつけてんの？

通信費節約

git merge --squashしてマージした後作業ブランチを削除したら
作業ブランチの履歴ってもうどこにも残らないっていう認識でいいの？

>>260
コミットIDを直接指定すれば見れるし、しばらくはgit reflogでコミットIDを知ることができる

>>261
どうもです
git gcとかしても残ってるって事かな？
何かすれば完全に消せるのかもしれないけど、やっぱり基本全部残るんだね

Gitのコミットメッセージの書き方
http://postd.cc/how-to-write-a-git-commit-message/

えっと、俺がいいたいのは、適当にコミット作るんじゃないってこと。

>>262
git reflog expireとかしてからgit gcかな？

ブランチはhead に付けたただのラベルだし、squash だろうがamend だろうが別のコミットが出来るだけだから原理的に消える道理がない。
その程度で履歴が無くなるなら scm としての価値は無いし、誰も使わないだろな。

>>265
いやいや、squashして意図的にブランチを消しててコミットIDを直で指定しないと見れないのに
消えてはいないっておかしいよ
つうかどこからも参照されてないんだから>>264で消える気がする

squashやamendやrebaseが行うのは履歴への追加じゃなくて履歴の改変なんだよね
追加された履歴は残っていく
改変された履歴は消える(しばらくはreflogやもしくはコミットID直接で参照できるけど)

scmは履歴を絶対改変すべきじゃないって主張する人たちは存在するね

msysgitってシンボリックリンク使えないの？

ってことはWindowsでgitをまともに使いたいと思ったら
Cygwinしかないってことなのかな？

git init
git add .
touch a.txt
git commit -m "initial commit"
git checkout -b develop
ここでいろいろコードを書くがコミットはまだしてない。
そしてここでinitial commitにb.txtを入れとけばよかったと後悔する。
initial commitにb.txtを含めて今の作業を続ける方法を教えてください

>>269
rm -rf .gitして、git initからやりなおす

>>269
git stash
git checkout master
git stash pop
git add b.txt
git commit --amend

>>271
gitの試験があったら絶対出そうな問題だな

gitをsvnのように厳格に扱うのは難しいな

gitはフィクション
svnはドキュメンタリー

コミットしていないとスタッシュされないのでしょうか

コミットしてないものを待避させるのがスタッシュ

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

Git 2.x シリーズの 6 つの素晴らしいフィーチャー
http://japan.blogs.atlassian.com/2015/10/cool-features-git-2-x/

リモートのリポジトリから特定のコミット時点のソースコード一式を取得するgitコマンドってあったりするの？
git cloneだとinitからそのコミットまでの繋がる歴史一式をダウンロードしちゃうじゃん
コンパイルしたいだけだから別に歴史いらないわけだし

自己解決
git clone --depth 1
ってすればよかったのね

msysとmsys2とmsysgitの関係について教えてくれ。

Windowsでgit使ってる人ってどれだけいるの？
みんなGUI？

基本SourceTree
細かいとこはCLI

CLIはmsys系ですか？それともcygwinですか？

Cygwinも入れてるけどSourceTreeから開けるターミナルで足りてる

SourceTreeからターミナル開けるのか。

何が開くんだろう？

入れるの面倒だからぐぐったらGit Bash（msysgit）って書いてあるな。

http://relx.jp/blog/?p=883

sourcetreeでコミットを無かったことにするのはどうやればいいの？
なんかrevertする方法しかでてこない

現在のブランチをこのコミットまでリセット

>>288
いっこずつ戻したいんだよなぁ

1個前のコミットが複数ある可能性があるからさ
特定のコミットへresetするか
いまのコミットをamendするか
どっちかになるわけよ

>>289
いっこづつ戻りながら>>288やればいいじゃん

特定のフォルダ以下はバージョンを最新のものしか保持しないように出来る？
出来るならやり方教えてください

>>292
最新のってどういう定義だよ？ リモートにあるのが最新？
それを更新するタイミングは？ 別ブランチに切り替えた時、残しておきたい？

出来ないというか、そんなのはバージョン管理じゃない。
同じバージョンから違うバイナリが出来てしまう。

それをやるならば、バージョン管理外のものとして自分でどうにかするしか無い。

1. 今のプロジェクトとは別のバージョン管理を行う。
外部ライブラリとかがこんな感じになってる。
場合によってはsubmoduleを使う。

2. ファイルをリポジトリに入れず、アプリ実行時にファイルがなければ
リポジトリに入れたテンプレートファイルからコピーする。

設定ファイルがこんな感じになってる。

テンプレートファイルの代わりに、最新のファイルでも
どこぞ好きな場所からコピーすればいい。

>>293
例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね
もちろん互換性を保持したままバージョンアップされる
コンバータをビルドするには環境を作成する必要があるからgit cloneで
バイナリだけ落ちてくればいい
もちろんツールのソースは別のリポジトリで管理されてる

単にディスクスペースを気にせずバイナリをcommitすれば全て解決だけど
履歴は要らないから簡単に保存しないように出来ればなと思っただけだ

hash-objectあたりを使いこなせれば出来そうな気がするけど簡単に
出来る方法があればと聞いてみた

>>294
> 例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね

いやだから、それはバージョン管理外の話だろ。

コンバータの実行ファイルをリポジトリに入れるのは、間違っている話で、
そういうのは、サーバーのセットアップとして、例えばgccコマンドのように
パッケージマネージャーや類似のシステム、それがなければ独自の配布手段で
インストールするものだぞ。

例えばrubyとかの世界ではGemfileをリポジトリに入れておいてBundlerコマンドで
Gemfileに書いてあるモジュール（コマンド含む）をインストールする。

> コンバータをビルドするには環境を作成する必要があるからgit cloneで
> バイナリだけ落ちてくればいい

単純にこの発想が間違いで、glt cloneで落ちてくる代わりに、
make-build-environment.sh とか作ってそれで落とせばいいわけさ。

もし、コンパイルが必要なソースコードであれば
makeファイルの中で落とせばいい。

なんでもgitでやろうとするなよ。

別に発想とか概念とかの指摘はいいよ
gitで簡単に出来ればやるし絶対出来ないんだったらやめるよ

ただProGitに公開鍵(もちろんバージョン管理は不要)をhash-objectで
格納する例があってそれが頭にあったってのもある

gitは根本的には仮想ファイルシステムなんだからhash-objectでやろうと思えば
望んだ動作が出来るはずだけど、そこまで理解出来てないからこれから考える

変更がなけりゃいくらコミットしてもコピーされないよ大抵の場合

ver1.0のソースコードの時にコンバーターの実行ファイルを追加しました。
ver2.0の時にコンバーターをアップデートしました。

後からver1.0のソースコードをビルドしたい時、
コンバーターは最新のものを使いたいです。ってことでしょ？

だから最初から普通にバージョン管理するべきじゃないって話をしてるのに。
できるかどうかじゃないんだよ。

v1.0からブランチ切って最新コンバータつっこめばいいだけじゃね？必要なら適当なタグもつけてやりゃいい

>>296
> なんでもgitでやろうとするなよ。
頭固いね。
Gitでバイナリファイルを管理したっていいじゃない。
こういう仕組みも用意されてるんだし。
https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7

>>301
いいんじゃない？バイナリーのgitでの管理
うちも結構やってるよ

でもバージョン管理したくない物をgitの管理下に置くのは
筋の悪い使い方のような気がするな
というか、俺はそのバイナリーもバージョン管理したい


俺だったらそのバージョン作成時のバイナリーファイルをgitに入れておいて
そのバイナリーの最新版を取得するスクリプトも一緒にgitに入れておくよ

そうすれば動作実績のある古いコードと古いバイナリーの組み合わせで現環境での動作を確認した上で
バイナリー部分を新しくして再作成できる

https://git-scm.com/book/ja/v2/Git-%E3%81%A7%E3%81%AE%E5%88%86%E6%95%A3%E4%BD%9C%E6%A5%AD-%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E9%81%8B%E5%96%B6
のリリース用のタグ付けに公開鍵をhash-objectを使って格納する例が載ってる

gitは柔軟な管理が出来るっていう1例だな
gitの内部構造をちゃんと把握出来れば最善な方法は分かるだろう
とりあえずそこまで分かってないと向いてる向いてないを言う事は出来ない
色々試してみるよ

バージョン番号を管理したいときにはgitは不向きなんだよね
かといってcvsに戻るのも面倒だし・・・

ツールに溺れてアホ。

>>301
> Gitでバイナリファイルを管理したっていいじゃない。
誰もバイナリファイルを管理するなって言ってないんだけど。

jpgとか一体何から生成するっていうんだ？
生成するソースがバイナリ形式しか無いものだっていくらでもある。

>>305
> バージョン番号を管理したいときにはgitは不向きなんだよね

バージョン番号をつける（にも使える）為の
git tagって機能があるよ。

>>302
> いいんじゃない？バイナリーのgitでの管理
> うちも結構やってるよ
>
> でもバージョン管理したくない物をgitの管理下に置くのは
> 筋の悪い使い方のような気がするな

そのとおりだよね。
バージョン管理したくないものを含めるなって言ってるのに、
いきなり（バージョン管理することも普通にある）
バイナリファイルを持ってきて反論したつもりとか意味不明すぎたｗ

>>308
> バージョン管理したくないものを含めるなって言ってるのに、
そうなの？
俺は、元発言者は、バイナリをバージョン管理したいと思ったが。
V1.0とV2.0があったとき、
・V1.0の完成時点のバイナリの何か
・V2.0の完成時点のバイナリの何か
を取得できないと後から困ったことになったりして、そのバイナリの何かをバージョン管理に
入れたいんじゃないのかと思ったが。

>>299
> ver1.0のソースコードの時にコンバーターの実行ファイルを追加しました。
> ver2.0の時にコンバーターをアップデートしました。
>
> 後からver1.0のソースコードをビルドしたい時、
> コンバーターは最新のものを使いたいです。ってことでしょ？

この例だと、最新のコンバータではV1.0をビルドできないから、V1.0時代のコンバータが必要とか。

まぁ、その必要なバイナリが、何かのエコシステムに入っていて、後からバージョン指定でいつでも
取り出せるようになってればいいけど、そうなってないバイナリの何かは、バイナリそのものを管理
しといたほうが楽じゃないか？

>>309
特定のフォルダ以下はバージョンを最新のものしか保持しないって
書いてあるだろ。

292 名前：デフォルトの名無しさん[sage] 投稿日：2015/11/04(水) 15:24:58.18 ID:4VARUgDB [1/3]
特定のフォルダ以下はバージョンを最新のものしか保持しないように出来る？
出来るならやり方教えてください

294 返信：デフォルトの名無しさん[sage] 投稿日：2015/11/04(水) 17:21:49.38 ID:4VARUgDB [2/3]
例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね
もちろん互換性を保持したままバージョンアップされる
コンバータをビルドするには環境を作成する必要があるからgit cloneで
バイナリだけ落ちてくればいい

>>311
最新のもの "しか" 保持しないというのは
言い換えると古いバイナリは保持しないってことだぞ。

バイナリであろうがなかろうが、
「それ（例：バイナリ）」が「あれ（例：ソース）」から自動的に生成可能なのであれば
「あれ」だけをバージョン管理すればいい。
「それ」は入れる必要が無い。

だけど「あれ」が入手不可能だったり自動的に生成するのが困難だったり
するばあいは「それ」を入れても構わんよ。それがバイナリであっても。

で、この話はしていない。


特定のフォルダ以下はバージョンを最新のものしか保持しないならば
最初からバージョン管理ツールで管理するなって話をしてるの。

converter_v1.exeとかconverter_v2.exeとかの名前でコミットしといて、
converter.exe自体はソース管理対象から外しておいて
converter_v1.exeとかconverter_v2.exeからconverter.exeへコピーしてビルドするとかじゃダメなの？

>>314
それは何が目的？

>>313
>>294で
> コンバータをビルドするには環境を作成する必要があるからgit cloneで
> バイナリだけ落ちてくればいい
> もちろんツールのソースは別のリポジトリで管理されてる

って言ってるじゃん
使う側はコンバータをビルドする環境が無いから(作成する必要もないから)
最新のコンバータだけcloneで他のソースとかと一緒に落ちてくればいいという事を言ってる

gitは仮想ファイルシステムでProGitでバージョン管理する必要の無い公開鍵を
hash-objectで格納する例が載ってるから、バイナリをそんな感じで管理したいって事

もうこれで3回も同じ事を書き込んでるけど、誰もhash-objectやgitの仕組みには
触れずに概念的な話しに終始してるよな…

そんなことはVCS全般すれでやればいい事でgitでどうやるかを聞いてるだけだ

>>316
じゃあ「特定のフォルダ以下はバージョンを最新のものしか保持しない」は
どういう意味？

最初に俺が、その質問者に意味を聞いてるんだけどなｗ
擁護するならあんたが答えてもいいよ。

>>317
特定のフォルダ以下にそういうコンバータがいくつもあって
いっぺんに指定したいってだけでしょ

>>318
意味不明。「最新のものしか保持しない」んだよ。
いくつもあるわけがない

最新のコンバータが1つのファイルとは限らないだろ
本体バイナリと設定ファイルで構成されるとか
バイナリだけだとしてもバックエンドとフロントエンドに分かれているとか

本人じゃないから実情は知らんけど

>もうこれで3回も同じ事を書き込んでるけど、誰もhash-objectやgitの仕組みには
>触れずに概念的な話しに終始してるよな…

皆筋悪そうだから他の方法すすめてるだけなのに
そんなにいいアイデアだと思うんなら自分でやってみて
「ぼくのかんがえたさいきょうの・・・」とかいう釣りタイトルつけて
ブログにでもうｐすれば。

>>313
> 最新のもの "しか" 保持しないというのは
> 言い換えると古いバイナリは保持しないってことだぞ。
俺が想像したのは、MyApp V1.0の時の最新と、MyApp V2.0の時の最新は違うということ。
V1.0一式を取得したら、そのときの最新のバイナリの何かが欲しいのではと。

> だけど「あれ」が入手不可能だったり自動的に生成するのが困難だったり
> するばあいは「それ」を入れても構わんよ。それがバイナリであっても。
>
> で、この話はしていない。
ソースからビルド可能なら、バイナリは管理するな、ビルドしろと読み取ったから少しコメント
したんだが、そういう話じゃないなら、俺からは以上かな。

>>322
読めばわかるでしょ？

その時の最新のバイナリではなくて、常に同じものが欲しいって書いてある。
古いコードをチェクアウトしたとき、当時の最新ではなくて現在の最新がほしいって書いてある。

なにそれ？バージョン管理の意味無いじゃん。って話をしてるからやめとけという話をしている。

バイナリを入れるのもあまり良くないが仕方ない場合もあるとして、
それ以上に古いコードを新しいツールでビルドするのも同一性が担保できないし、
百歩譲ってそれでいいにしても、それならそれでバージョン管理をしなければいいだけ。

単に「ファイルを取ってくるのが面倒くさい」という理由だけで、
バージョン管理ソフトをバージョン管理ではない使い方をしようとしてるんだよ。

なぁ？センス無いだろー？ｗ

gitはファイルストレージじゃないんだからリポジトリを肥大化させるバイナリを入れるなでFA

>>323
現在の最新って何かな？
特定のブランチをcheckoutすればそのブランチにおける最新のファイルが全部ワークツリーに展開されるよね？
指定したディレクトリの下だけは、ブランチの最新じゃなくて、リポジトリに存在するそのディレクトリの最新のツリーオブジェクトに置き換えるってこと？

>>323
ところで、Webアプリ開発で、external compiled/minified js/css libraryを、自リポジトリに
入れることについてはどう思う？

これを入れて良いと考えるなら、コンバータ的な何かのバイナリを自リポジトリに入れても
違和感ないと思うんだが。

なんでこう次からから次へと同じ間違いしてる奴ばかり来るんだ？
俺はバイナリも生成したファイルを入れることも否定してないんだよ。

「バージョン管理をしないもの」をバージョン管理システムに
入れるなって話をしてる。

いいかげんにしろ。ちゃんと読んでからレスしろ

>>325
言ってるのは俺じゃないぞ、例のあいつ曰く。

新しいファイルをコミットししたら、
過去の歴史のどのコミットをチェックアウトしても
あるディレクトリ以下だけは最後にコミットしたファイルを使いたいって言ってるんだよ。

繰り返し言うが、俺じゃないぞ。
あいつがそうしたいって言ってるんだよ。

↓これな
> 292 名前：デフォルトの名無しさん[sage] 投稿日：2015/11/04(水) 15:24:58.18 ID:4VARUgDB [1/3]
> 特定のフォルダ以下はバージョンを最新のものしか保持しないように出来る？
> 出来るならやり方教えてください


だから俺はバージョン管理しないなら、
バージョン管理システムに入れるなって言ってる。

>>328
それがもとなのか
でも >>293 の書き込みから推測すると
これは指定フォルダ範囲限定のshallow cloneしたいと言ってるように思える
指定フォルダ範囲以外は過去の履歴全部cloneやpullしたいけど
指定フォルダ範囲だけは最新のファイルだけ(-depth 1)cloneやpullしたいみたいな感じ？

>>293じゃないや>>292ね

> それがもとなのか
> でも >>293 の書き込みから推測すると

>>293は俺だよ。>>292へのレスだろうが。

>>330
それのレスを見る前に>>331を書き込んだ。

>>292=294が言ってるだろ

> コンバータをビルドするには環境を作成する必要があるからgit cloneで
> バイナリだけ落ちてくればいい
> もちろんツールのソースは別のリポジトリで管理されてる
>
> 単にディスクスペースを気にせずバイナリをcommitすれば全て解決だけど
> 履歴は要らないから簡単に保存しないように出来ればなと思っただけだ


1. 履歴は要らないと言ってるから、やっぱり最新版だけ欲しいだけ。

2. git cloneでバイナリを落としたいと言ってる。
単に別コマンドが面倒ってだけ。


別コマンドを入力するのが面倒だからという理由だけで
バージョン管理しないものを、バージョン管理システムに入れようとしてる。
俺は最初から、入れずに別から持って来いって話をしてる。

一般に用いられてるrubyのGemfileとかそういう仕組だろうが。
バージョン管理システムでやることじゃない。
ソースコードに含まれるビルドの仕組みでやるべきことだ。

思うに元の質問者は一部ディレクトリには最新版を強要するというバージョン管理をやりたいのではなかろうか？

>>333
その最新版っていうのはブランチの？ローカルリポジトリの？リモートまでも含めた全ブランチの？

>>332
> 一般に用いられてるrubyのGemfileとかそういう仕組だろうが。
> バージョン管理システムでやることじゃない。
> ソースコードに含まれるビルドの仕組みでやるべきことだ。
べきって言われると、何か反応したくなっちゃうんだよね。
gemに代用されるパッケージマネージャは、おおむね取得後ビルドが必要ない言語とか、
グローバル環境を汚染しない目的で使われるとかあるからね。

欲しいファイルが*.soいくつかとか、*.warいくつか、だったら、バイナリをリポジトリに
入れてもいいと思うんだけど。

gitをただのバージョン管理システムって決め付けてる奴はgithubなんて
一生思いつかないんだろうな
git lfsとかもバージョン管理システムで巨大なバイナリなんて管理するなって
言うんだろうな

元質問者の意図がわからないので俺に理解できる形に問題を改変

・一部ディレクトリで最新版を強要するバージョン管理を行いたい
最新版の意味は別途定義する

例
proj
-src
-tools
プロジェクトディレクトリの下にsrcディレクトリとtoolsディレクトリを置く
srcは普通にバージョン管理を行う
srcの過去バージョンをチェックアウトした場合でもtoolsディレクトリは常に登録されている最新情報を示すように強制する

最新版の意味は取り敢えずremote mster HEADと定義してみる

思い付いたやり方
フックスクリプト書いて全体のチェックアウト後とクローン後にtoolsディレクトリだけremote master HEADから取ってくるようにする

質問者の意図通りかどうかは知らん

>>336
> gitをただのバージョン管理システムって決め付けてる奴はgithubなんて
> 一生思いつかないんだろうな

githubはgitじゃないんですが・・・？

質問者は名前欄を工夫してくれ
質問者そっちのけで議論してあってたらバカみたいじゃないか

>>338
ソースが公開されて無い以上gitをどう改良してどう実装してるかなんて
分かりようがないけど、githubの実装を知ってるの？

なにいってんだこいつ

>>340が面白いことを言い出した（笑）

githubはgitを内部に取り込んで改良して動かしてると思ってるんだね。

素のgitのリモートリポジトリにアクセスするウェブサービスだよ。
githubはgitから見れば1クライアントにすぎない。

少し修正

githubはgitリモートリポジトリから見れば1クライアントにすぎない。

>>342
じゃあgitコマンドからはアクセスできないリソースはどうやって管理されてるか
知ってんの？

>>342
git lfsはGithub独自サービスだけどgitのプラグイン(?)で実装されてるよね
git lfsって出来るんだから
プラグインとか良く知らんけど他のGithubのリソースはプラグインとかではなくて
絶対にgitとは無関係なもので管理されてると言いたいんだよね？

>>342
githubのWikiとか当然clone出来るけど何を持ってただのクライアントと
言ってんだろうか…
バージョン管理以上の事をgitを使ってやってるって事を言いたいだけなんだが

git lfs持ち出してきて何か反論してるつもりなんだろうか？

俺が（何度も）言ってるのは、gitでバージョン管理しないものを入れるな
ということであって、バイナリを入れるなとは言っていない（推奨はしないけど）
バージョン管理しないものを、gitに入れるなって話をしてる。

で、git lfsは「gitにバイナリを入れるという標準機能」を高速化した
バージョン管理の仕組み。これはバージョン管理してるのだから、
俺が言っていることにたいしての、反証にはなってない。

>>344
> じゃあgitコマンドからはアクセスできないリソースはどうやって管理されてるか

Issueとかですか？ あれはgitでバージョン管理していません。
バージョン管理しないものをgitに入れるわけないじゃないですかーｗ

>>345
> プラグインとか良く知らんけど他のGithubのリソースはプラグインとかではなくて
> 絶対にgitとは無関係なもので管理されてると言いたいんだよね？

プラグインを使って連携して、情報をgitリポジトリではなく他のストレージに入れているのであれば、
それは俺が言ってる「gitリポジトリにバージョン管理しないものを入れない」ってことだよ。

もしgitリポジトリに入っているのであれば、git cloneした時に、
それらの情報が入ってるはずでしょう。

githubの仕組みは公開されていないだろうから、知る手段はないかもだけど
オープンソースgithubクローンのgitlabを参考にしてみたら？

あれは「gitリポジトリに入れるべきじゃないバージョン管理しない情報」の保存に
PostgreSQLを使用している。githubも同じであることにはならないけど、
そんなものをgitリポジトリに入れずに作れることの証明にはなる。

一応釘を差しておくわ。

バージョン管理しないものをgitリポジトリに入れるなと最初から言ってるだけ、

バイナリを入れるなとは言ってないし、githubがgitと連携してないとも言ってない。

どうも俺が言ったことを捻じ曲げようとしてるやつがいるようなんだよな。
わざとか？

>>339
名寄せしてみたYO
ID:4VARUgDB=ID:Rz7aBIc4
ID:skpMWGee=ID:DwMhKH/P=ID:0X5/TYar
ID:raJNtqbt=ID:BnMLfISE

>>348
issueとかって言ってるけどwikiは標準のgitだけでcloneできる

>>321
> 皆筋悪そうだから他の方法すすめてるだけなのに
筋悪いって…なんとう文学的な否定の仕方ｗ
完全文系だよな
hash-objectを良く知らないと正直に言うか黙ってるか具体的に否定してくれよ
ちゃんと否定してくれればありがとうと言うよ

>>352
issueって言ってるのに、なんでwikiって言ってるんだ？
wikiはドキュメントであり、バージョン管理するものだろう？

「とか」を突付いてるんじゃね？
にしても何が言いたいんだろうな？

>>353
hash-objectがあるから、だからなんなんだ？としか思ってない。

本来の用途ではない使い方をするというのであれば
hash-objectを使ってデータベースサーバー用の
データストレージを作ることだって可能だろう。

hash-objectを使って可能だとしても
バージョン管理システムにバージョン管理しないものを入れるべきではない。

本来の用途ではないからだ。

git checkout [ブランチ名] する時に、
1. その名前のブランチがなくて
2. その名前のブランチがリモートにある場合、

自動的に、リモートブランチをトラッキングした
ローカルブランチが新しくできるよな？ 実際に出来てるし。

だけどCygwinのgit 2.5.3だと、エラーにならないくせに
ローカルブランチができていない。（名前を間違ったらエラーになる）

これってバグか仕様？ それとも何か設定でもある？

これだとうまくいく
git checkout -b foo --track origin/foo
git checkout --track origin/foo

branch.autosetupmerge かな？

>>358
違うみたい。true、 always のどちらでもやったけど、新しくブランチが作成されない。
新しくブランチが作成されないのに正常終了してるからバグなんじゃないかって思ってる。

確かgit 1.7とか古い時代は、git checkout [ブランチ名]だけでは
リモートに同じ名前があったとしても、ブランチ作成されなかったんだよね。

いつの頃だったか忘れたけど、（リモート）ブランチ名を指定して
チェックアウトするだけでローカルにブランチ作られて更に
トラッキングされた状態になるようになったから、便利！って思って
それ以降いつもブランチ名だけ指定していたから、cygwinでやってあれ？ってなった。

>>353
hash-objectで何をどうやりたいの？
あれは単にgitの内部構造なだけで
あなたのやりたいことを実現する魔法の道具ではないよ

まず自分がやりたいことを明確にする
そしてそれを他の人が理解できる形にする

それが出来れば具体的なアドバイスが得られれると思うよ

> hash-objectで何をどうやりたいの？
バージョン管理ソフトを使って
バージョン管理をしたくない。
常に最新のファイルだけを保存したい。

バージョンを管理しないのに最新とか意味がわからん

>>361
＞常に最新のファイルだけを保存したい。

「常に最新のファイル」を定義してみて
あなたにとっての「最新のファイル」が何を意味するものなのか他の人にはわからないよ



ちゅうか元質問者が誰かすでにわからないんだったな
まぁいいや

例えばコンパイラは古いバージョンを使う必要はない。
git cloneしたらコンパイラも一緒にインストールされて
makeを実行したらすぐにビルドしたいんだよ。

>>294に書いてあるとおり

> 例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね
> もちろん互換性を保持したままバージョンアップされる
> コンバータをビルドするには環境を作成する必要があるからgit cloneで
> バイナリだけ落ちてくればいい

>>364
オッケー
例えばそのコンパイラは、コンパイラ開発サイトにある最新版なのか
自分たちのプロジェクトの中にある最新版なのか
どちらが欲しい？

そもそも、元発言者が、過去のバージョンを取得したときのコンバータのバージョンがどうあるべきなのかを
言ってないので、それ抜きに議論しても無意味。

>>364
その最新版？のコンパイラを常に誰かがビルドしてどこかにアップロードしてくれているという前提なら
post-merge フック使ってそれをワークツリーにダウンロードしてくればいいだけかな

>>367
> 例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね
って言ってるよ

あと
> 単にディスクスペースを気にせずバイナリをcommitすれば全て解決だけど
> 履歴は要らないから簡単に保存しないように出来ればなと思っただけだ

って単に履歴が要らいってだけだろ
長々と書き込みがあったけど要するに履歴を保存しないのは無理っていう結論でFAだろ？

>>369
だからその最新版でありさえすればいいを定義してないから混乱してるんだって

>>369
> > 例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね
> って言ってるよ
いやだから、
2015-01-01: app ver 1.0 release, converter ver 2.0
2015-10-01: app ver 2.0 release, converter ver 2.5
だったときに、app v1.0を取得したときに本当にconverter v2.5でいいのかねという疑問があるのだが。

普通に考えればconverterもgitに登録すればいいのだが、サイズがでかいとかの理由で
そうしたくないなら、別の方法を考える必要がある。

>>370
定義っていうか、だから履歴が要らないって事だよ
コンバータ自体は多分しょっちゅう更新されてんだろ
で、互換性が保たれてるから他のソースのどんな時点のチェックアウトでも
最新のコンバータが存在してればいいって事でしょ

だから普通にコミットした時点で古いチェックアウトで古いコンバータが
落ちてきちゃうから無理って事でFAでしょ？
hash-objectとかよく分からないけどそういうのを駆使すれば可能かもね
そこまでやる意味があるか分からないけど出来るのならやり方は知りたいけど

>>372
> で、互換性が保たれてるから他のソースのどんな時点のチェックアウトでも
> 最新のコンバータが存在してればいいって事でしょ
でも、app v1.0とconverter v2.5の組み合わせでの動作確認は誰もしてないよ？
それでもいいの？

>>372
あなたは>>292の元質問者？

>>372
＞だから普通にコミットした時点で古いチェックアウトで古いコンバータが
＞落ちてきちゃうから無理って事でFAでしょ？

ここだけならpost-checkoutフックで動作するスクリプト書くのがいいと思うな
progitにもそう書いてあるし

git pullしたときに更新があったら~/install.shを実行する方法を教えて

>>373
それはコンバータ作成者が古いデータかソースともテストすればいいだけじゃないか？
当然テストが全部通ったものがアップされてる前提でしょ

>>376
post-merge フック

例えばnode.jsとかnodeが頻繁にバージョンアップしている。
リポジトリにnode.jsを入れておけば
git cloneするだけですぐに動かすことができるだろ？
便利じゃん。

最初から言われているように、バージョン管理しないものを
バージョン管理システムに入れるのが間違い。
横着してないでコンバーターを別にインストールすればいいだけ。

入れたきゃ入れればいいじゃん？
でも、あくまでバージョン管理する事が目的のツールなんだから、履歴が消せないくらいは我慢しなよ。
簡単に消せたら逆に困るわ。

バージョンアップの都度cloneし直すのか。
発狂しそうになるな。

>>381
普通に入れたら、古いコードをチェックアウトした時に
古いコンパイラやコンバーターになるじゃん。
それじゃだめなんだよ！

sourcetreeで スタッシュからポップしたいんだけどどうしたらいいの？

>>383
だからpost-checkoutスクリプト書けって言ってんだろ
ソースに付属のサンプルくらい読めやがれ

>>377
普通は、利用される側は利用する側のテストはしない。
>>371の例で言えば、converter作成者はappのテストはしない。
（というか、converter v2.0リリース時にはapp v1.0は存在しないのでテストできない）

> 古いコンパイラやコンバーターになるじゃん。
> それじゃだめなんだよ！
それで駄目かどうかは、元発言者しかしらない。

で、あなたは元発言者なの？

>>385
post-checkoutスクリプトでどうやって
git cloneしたときコンバーターまでインストールしますか？
フックをどうやってgitリポジトリに入れるんですかね。
いいですか？git cloneしたときに開発環境をセットアップしたいんですよ。

>>387
あなたは元発言者？

>>388
はいそうです。

>>389
OK、じや、最新版のgitを使え

その証拠に最初の書き込みを書いておきますね。

292 名前：デフォルトの名無しさん[sage] 投稿日：2015/11/04(水) 15:24:58.18 ID:4VARUgDB [1/3]
特定のフォルダ以下はバージョンを最新のものしか保持しないように出来る？
出来るならやり方教えてください

294 返信：デフォルトの名無しさん[sage] 投稿日：2015/11/04(水) 17:21:49.38 ID:4VARUgDB [2/3]
>>293
例えばコンバータの実行ファイルとか最新でありさえすればいいものとかね
もちろん互換性を保持したままバージョンアップされる
コンバータをビルドするには環境を作成する必要があるからgit cloneで
バイナリだけ落ちてくればいい
もちろんツールのソースは別のリポジトリで管理されてる

単にディスクスペースを気にせずバイナリをcommitすれば全て解決だけど
履歴は要らないから簡単に保存しないように出来ればなと思っただけだ

>>390
使ってます

>>392
じゃgitのバージョンと実行環境は？

最新は2.6.3だろ。何を言ってるんだ？

>>389
元発言者なら、>>373の質問に答えてくれ。

まさかフックの共有の仕方も知らんやつが
hash-objectを駆使すれば実現できるはず(ｷﾘ
とか言ってて草

>>387>>389は偽モンだろ
口調が全然違う

結論出てるのに蒸し返す方が草だろ

qiitaでこういうときはこういうコマンドと引数を使えみたいな記事を定期的に出てくるけど
あんな長いものを入力しないといけないの？
init,clone,checkout,commit,add,branch,log,reflog,rebase,merge,pull,pushのみ使ってるけどcommit -mとcheckout -f .以外それぞれの引数なんて何もしらないよ
bitbucketにリポジトリ作るときのremoteの設定なんてコピペ。

シェルのgitコマンド補完用の設定をしてあれば
長いオプションも引数もある程度補完が効くから何からなにまで入力しなきゃいけないってことは無い
まあメモしといてコピペも使うし、頻繁に使うのはエイリアスやシェル関数を定義するけどね

　　　　　　　自民党　対　国民！　　死者数、戦時なみに！


川崎病の年間患者数、史上最高に　1万5千人を突破、ピーク時を超える　最初の報告は水爆実験後。本当の原因は被曝
震災以降に死亡者数が、第二次大戦に匹敵するほど急増している
厚生労働省によると平成２３年から平成２５年の累計死亡者数は３６０万人以上に急増。今の日本は太平洋戦争時の時と同じくらいの勢いで人が亡くなっている
https://twitter.com/tokai amada/status/664927655544795136

除染袋回収の作業員５人 疲労で動けず、自衛隊など救助　　疲労じゃないだろう、被曝障害だろうよ　死んだように眠る人々（写真多数）
http://s.ameblo.jp/kaito000777/entry-12031605335.html

【川島なお美の食べて応援が恐怖すぎる】自宅でも進んで食べて応援
1年後・軽くぶつけただけで肋骨骨折　2年後・眼球から出血は半年に一度　3年後・胆管に腫瘍、血液検査は異状無し　4年後・逝去 夫は片目失明、愛犬もがん
https://twitter.com/2ch_NPP_info/status/648256313571479552

・・・ 今も、原子力緊急事態宣言中… 対策本部長は安倍首相。


　　　　　　　　安倍が国民を被爆させながら核兵器を密造している！？

三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある　書けばツイッターで速攻削除されている
https://twitter.com/toka iamada/status/664017453324726272

安倍晋三の兄が関与している三菱重工　核開発疑惑について いくつかツイートしたが、反応がないから変だと思って、自分のタイムラインを調べてみたら、
完全に削除されていた　私のツイートで、安倍政権に都合の悪い情報は速攻削除されている これは驚いた　ここまでやるのか
https://twitter.com/toka iamada/status/664016524592574464

先ほど、まだ数分以内に、三菱重工の核開発疑惑について、いくつかツイートしたが、検索しても出てこない　多くの人のタイムラインに出てこない ツイート直後に消されてしまったようだ
https://twitter.com/toka iamada/status/664015521830952960

質問です。

プライベートリポジトリが欲しいのでgithubではなくgitlabを使ってるんだけど、
プライベートだから当然認証がある。

そのリポジトリにあるファイルをcurlかwgetで取得したいんだけどどうすればいい？
認証の仕方がよくわからない。BASIC認証？






答えです。

curl、wgetに--headerオプションでプライベートトークンを付けて実行すれば良い。
プライベートトークンはgitlabのプロファイルの所に書いてある。

curl --header "PRIVATE-TOKEN: トークン" "http://ホスト/api/v3/projects/123/repository/blobs/master?filepath=README.md"
wget --header "PRIVATE-TOKEN: トークン" -q -O - "http://ホスト/api/v3/projects/123/repository/blobs/master?filepath=README.md"

プロジェクトのIDの123は、http://ホスト/api/v3/projects にアクセスすれば調べられる。

参考
http://doc.gitlab.com/ce/api/
http://doc.gitlab.com/ce/api/repositories.html





以上、個人用メモな

プライベートに限らずプッシュするならどんな場合でも認証あるでしょ？

curl,wget限定か、historyにパス残したくないからってことか

>>403
> プライベートに限らずプッシュするならどんな場合でも認証あるでしょ？
パブリックリポジトリから、取得するだけなら要らないだろｗ
githubからパスワード使わずに取得してるでしょ。

>>404
> curl,wget限定か、historyにパス残したくないからってことか
というよりもgitlab（おそらくgithubとか最近のサービス全般だろうけど）では
ヘッダーにトークン埋め込んでアクセスするんだよ。

ヘッダーを入れられるならばcurlやwgetじゃなくてもいい。

プライベートトークンもパスワードと同じようなものでhistoryに残さない方がいい。
もっともパスワードと違って簡単に変更できるけど。

>>405
プッシュと書いている時点で取得するだけではないんじゃ

GitHubでリポジトリを新規作成すると
以下のような案内が出てくる。



この中のコマンドにミスがあるんだけど、
わかるやついる？

え、質問じゃなくてクイズってこと？
うーんわからん

>>408

そうそう、質問じゃなくてクイズだよ！
書いてある通りに実行してみると気づくんだけど
見てるだけだとわかりづらい。
俺は見ただけですぐ気付いたけどｗ
もうGitHubタンどじなんだから〜！

コマンドプロンプト起動して試してみたけど何の問題もなかったけど

3でコミットしてないとかかな
でも3は既存プロジェクトをpushしろって内容だし違うよなあ

>>406
> プッシュと書いている時点で取得するだけではないんじゃ

プッシュと書いてませんが？

>>407
最近bashでプログラミングしていたからねｗ
それじゃ、README.mdは作成できないね。

>>413
そう！それ！

>>410
あ、わるい、おれLinux環境なんだけど、Windowsではうまくいくのか。

一応、用意してた正解を載せておくと、

echo # Test-Remote-Repository >> README.md

このコマンドの#以降はシェルでコメントとみなされてしまうため、
README.mdファイルは作成されない。
よって

git add README.md

でエラー。

WindowsでもLinuxでもどっちでもOKな表記にするにはどうすればいいのか考えたけど、

echo '# Test-Remote-Repository' >> README.md
echo "# Test-Remote-Repository" >> README.md

シングルクオートもダブルクオートもLinuxはOKになるけど、
WindowsがNGになってしまうね。。。

誰かWindowsでもLinuxでも動くようにする方法わかるやついる？

GitHubのコマンドの説明がまさかWindows用だったとはな・・・、
ある意味Gitの巣立ちを実感するが。。。

>>413
俺は「Git Bash」使ってる。
プログラミングはVSだけど、GitはGit Bash使ってる。
コマンドプロンプトなんて使えたもんじゃないけど、
Linux知らない人たちはそれが普通だと思ってるから問題ないんだよね。
君はコマンドプロンプトとシェルのどっち使ってる？

あ、なるほどなw すっきりしたのと面白いご指摘だった
みんなエディタでやってるのかな

俺はコマンドプロンプトの代わりにLinuxを使ってるよ。


コマンドプロンプトを起動するのもputtyを起動して
仮想マシンのLinuxに接続するのもたいして変わらん。

編集にはWindows側のSublime Textを使ってる。
ローカルディスクのファイルを読み書きするのも
仮想マシンのLinuxにSamba経由で読み書きするのもたいして変わらん。

ま、Vagrantで仮想マシンのLinuxを起動する所までは
コマンドプロンプトの代わりにCygwin使ってるけどな。

>>412
403の「プッシュするなら認証あるでしょ」に対して、
405で「取得するだけなら要らないだろ」と返事しているけれど、405のその話ではもうプッシュは関係なくなっているのかい？
そしたら会話として成り立ってないよな。

「信号赤なら交差点渡っちゃだめだろ」に対して、「信号青なら渡ってもいいんだぞ」って言ってるようなもんだよ？

あなたはプッシュと書いてないかもしれんが、プッシュ前提の書き込みにレスしてる時点でプッシュと書いてるのと同じだと思うんだが

>>403の「プッシュするなら認証あるでしょ」の前に
>>402では取得したいと書いてあるのに、

>>403のその話では、どこからプッシュがでてくるのかい？

そしたら会話として成り立ってないよな。
>>403がね。

プライベートなのにhttpでパス入力無しで取ろうと思うのがそもそもの間違い
結局ファイルにパス書いておくんじゃヒストリーと変わらん

>>420
> プライベートなのにhttpでパス入力無しで取ろうと思うのがそもそもの間違い
いやな、プライベートっていうのは今だけで、将来パブリックにするのよ。
そんときな、ウェブからインストールするやつあるだろ？　こういうのだよ。

https://github.com/yyuu/pyenv-installer
> $ curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash

インストーラーに限らないけど、直接ファイルを参照する必要がある事柄の
テストをしたいわけだよ。

> 結局ファイルにパス書いておくんじゃヒストリーと変わらん
何を言ってるのかわからん。 事例に出してるPRIVATE-TOKENはコマンドラインだし、
ヒストリーに入れたくなければ、コマンド打つ時に頭にスペース入れればいいのよ？ （設定による）

それにSSHの秘密鍵は、ファイルにパス書いてあるよね？　あれが安全とされる理由は
パーミッションを600にしているからだよ。それと同じようにすればいい。


君、全体的に、考慮と経験が足りないなぁ。

SSHの秘密鍵は0600にしてるだけじゃ安全性に問題があるから
更に暗号化してパスフレーズ無しでは解読できにくくして運用するのが普通

ちょっと経験が足りませんね

>>422
パスフレーズありだとバックアップ処理などの自動的に行う処理ができません。

パスフレーズはセキュリティ強化するためのもので必須ではないでしょう

経験が足りないのはどっちｗ

>>419
なるほどな。だとしたら答えはこうだな。403は新しい話をし始めている。405はそれを理解できず意味不明なレスをしている。
402「通行規制がかかっているので交差点が渡れない」
403「信号赤のときも渡れないよね？」
405「>>403 信号青の時は渡れるだろw」

× 403は新しい話をし始めている
○ 403は見当違いの意味不明なレスをしている

>>425
そうかもしれんが405が意味不明なのは変わらんぞ

>>423
>パスフレーズありだとバックアップ処理などの自動的に行う処理ができません。

普通エージェントを使います。

>経験が足りないのはどっちｗ
圧倒的にお前。

それじゃパスフレーズの意味ないだろｗ

PCを再起動した後の、夜間バックアップとかどうするんだ？
手動でリスタートかｗ

クライアントPCを安全に使いたい人と
自動テストを組みたい人の
永遠に噛みあわない会話

というか、単なる開発中の安全である必要が無い
パスワード（パスワードトークン）までコマンドラインで打つな
ファイルにパスワードを書くな、とか言っている奴がいるだけの話。

自動テストのためにTravis CIがgithubからコードを取得する時に
SSHを使ってコードを取得していて、しかもパスコードがかかっている
SSH鍵を利用する時にキーエージェントを使っていると思ってるのかｗ
パスコードはTravisCIの社員が入力しているのかな？ｗ

git init
touch README.md && git add . && git commit -m "initial commit"
touch a && git add . && git commit -m "add a"
touch b && git add . && git commit -m "add b"
ここで3番目のコミットを2番目のコミットにまとめたいので
git rebase -iしても
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-rebase(1) for details（略）
ってでてrebaseの編集画面が出ません
ブランチ変えてコミットしたものならrebase出来ますがmasterだとrebaseできないんでしょうか？

>>433
たぶんrebaseの使い方を勘違いしてる

>>433
英語のメッセージ読もうず

WindowsのコマンドプロンプトからでGit Bashを起動するとき

START %USERPROFILE%\AppData\Local\Programs\Git\git-bash.exe
と
START %USERPROFILE%\AppData\Local\Programs\Git\bin\sh.exe --login -i
の
前者と後者でGit Bashを使う上での機能的な違いがあったりしますか？
前者はGit for Windowsをインストールしたプログラムメニューのショートカットのリンクからので
後者は昔のmsysGitをインストールした時のプログラムメニューのショートカットのリンクなんですけどGit for Windowsでも使えてます

この疑問は単純に好奇心で違いが知りたいだけであって深い意味はないです

shだと(shがbashへのシンボリックリンクであったとしても)、bash拡張が使えないと思う。
diff <(ls /dir1) <(ls /dir2)みたいなものとか。
.の挙動も違うみたい。
http://sechiro.hatenablog.com/entry/20120806/1344267619

shがWindowsのショートカットでbashに割り当てられてる場合はどうなるか、ちょっと手元に環境がないのでわからないけど。

説明不足ですみません
git for windowsのインストールディレクトリ下の/bin下に sh.exe と bash.exe の両方が別々のファイルとしてあって完全同一ファイルです
>>436の前者のは/bin下ではなくインストールディレクトリ直下にあるgit-bash.exeでランチャー的なものと推定されるのですが
git for windowsのリポジトリ調べるのも面倒なんでgit-bash.exeはどんな挙動してるのか知ってる人いたらおせーて的な疑問です、はい

>>438
bin/bash.exeとbin/sh.exeの違いはman bashに色々書いてあるからそれを見るとして
git-bash.exeとbin/sh.exeの違いは前者が端末エミュレータ込みで別画面に起動するが
後者は単なるシェルコマンドでDOS窓内で実行される

正直実行すれば一目瞭然で聞くまでもないと思うが…

Windows版Git入れてgit-bash.exeを使えば遅いがまっとうな端末エミュと
大量のMSYS2のコマンドが入るからcygwinとか要らなくなった
マジありがたい

msys2もcygwinもあまり変わらないけどな。

cygwinからPOSIX互換機能を除いた
劣化版cygwinがmsys2と言っても過言じゃないし。

どんだけ劣化してるのか分からんがほとんどのコマンドは移植されてて
PATH関連で他のWindowsアプリとの親和性が良くなってるから言う事ないよ
逆にどこにまずい点があるのか知りたい

git-bashで
ls /c/Users
ls c:/Users
ls 'c:\Users'
が全て同じ結果になるけど、これこそみんな望んでいたことでしょ
git.exeとかも同じだけどなぜか/c/の指定はgit-bashから実行した時だけうまく動く
別に困ることは無いけど

>>442
それでも足りないコマンドがあるからな。

つい今もcolumnコマンドが入ってなくて愕然とした。

今度はbcが入ってなかった。

git.exeのついでにインストールされるだけだからコマンドが足りないのはしょうがないな
そこまで必要なら普通にMSYS2を入れればいいだけだ

そこで普通にCygwinを入れてるっていうわけ。
こっちがオリジナルだしね。

cygwinのコマンドはPATHの扱いで困るでしょ
困らないなら結局一緒だけど

何が困るの？

>>449
cygwinのgrepにc:\Hoge\hoge.txtとか指定して問題無かったっけ？
それで問題無ければ問題無いけど、そうするとMSYS2の意味無いしな…

補足すると、普通のアプリが使うようにいわゆるDOS窓でcygwin版のgrep.exeに
grep.exe hoge c:\Hoge\hoge.txt
で問題無く使えるかどうかだな

> git-bashで
> ls /c/Users
> ls c:/Users
> ls 'c:\Users'
> が全て同じ結果になるけど

ls /c/Users => ls /cygdrive/Users
ls c:/Users => 動く
ls 'c:\Users' => 動く

なんだ、動くじゃん。
一番上はマウントする場所の違いってだけだろう。

msysはcygwinのフォーク何だから、
そういう基本的な所はcygwinの機能だろう。

さくっと見つかった。

いちいち"/cygdrive/c"っていれるのが面倒なので、"/c"ってなるようマウントテーブルをいじる
http://d.hatena.ne.jp/snaka72/20100605/1275733012

最新から10番目の過去のコミットのときのファイルの全文がみたいんですが
git show HEAD@{10} test.txt
だと全文取れませんでした
わざわざcheckoutするのも面倒くさくてちょっと確認しただけなんですが
showコマンドで全文取る方法を教えてください

git cat-file -p HEAD@{10}:test.txt

showコマンドで全文取る方法は知らない

cat-file知りませんでしたこれ使わせていただきます

show もコロン

addってなんの意味があるの？
直接commitじゃダメなの？

今すぐコミットしたいものとあとでコミットしたいものを分けられる

git commit --amendで直前のコミットしたりrebaseするとコミットIDが変わりますよね
pushする前だったらコミットIDが変わっても問題ないですか？

push前のコミットがどう変わろうと自分にしか影響無いのに何が心配なんだ？

プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/

linusは2度革命を起こした。
1度目はlinuxカーネル、2度目はgitだ。

そして、gitも採用しているコマンドライン形式を考案したのが、
北海道に住む日本人医師であることは、
日本人がソフトウェアの世界に与えた効果として最大級のものだ。
ソフトウェアのmemeを生んだと言える。

git diffすると
-
-
-
+
+
+
な風に古いコードと新しいコードが分かれて表示されますが
修正した行が長いと読みにくいので
-
+
-
+
-
+
な風に一行毎に見えるようにするほうほうありませんか？

改行と空行で調整しる

行の増減があったらずれてかえって見づらくなるから、使える場面は限られるだろう。
diffが見にくいならdiiftoolで適当な外部ツールを使うのが吉。

--word-diff ではあかんか

side-by-side 形式が求めるものかな

>>464
gitの標準機能じゃないけど、icdiffがおすすめです

>>464
人間がみて切りの良い場所とdiffが判断する切りの良い場所が常に一致するとは限らないからなぁ

masterブランチにa.txtがあります
a.txtを大掛かりに編集するのでdevelopブランチを切ってそこで作業をしたいです
ベースとなるa.txtを見ながら作業したいのでa.txtをコピーしたb.txtを作成しました
このb.txtをmasterブランチのa.txtに反映させる方法を教えてください

git checkout -m master
git branch -d develop
cp b.txt a.txt
git commit -a

>>471
1. a.txtをテキストエディタで開く
2. developブランチに移動する
3. a.txtを見ながら作業をする

素人じゃねぇんだからさ、GUIで
マルチウインドウぐらい普通に使えよ。

>>471
あと別解としてa.txtをブラウザで表示するっていうのも有るな。
リモートリポジトリがあって、その内容をブラウザで見れることが前提だが。

>>471
なんでbを見ながらaを編集しなかった？

>>471は>>472で答えが出てるのに>>473-475はなぜか
何かを見ながら作業する事について返答してるな･･･

何かを見ながら作業したいのなら、それを見ればいいだけなので
コミットする必要が無いって話なんだが

ブランチで大きな変更をしたんだからコミットは必要じゃないの？
要するにそもそもコピーなんかするなよという前提を突っこんでのか

いっぽうを修正して、いっぽうは見るだけなんだろ？
見るだけなら表示するだけでいいじゃねーか

>>471>>472
developブランチ「俺はなぜ生まれてきたのか？」

>>480
細かくcommitしながらコーディングしたいからでは？

細かくcommitするのに
「このb.txtをmasterブランチのa.txtに反映させる方法を教えてください」
とかワケワカメ

本当にやりたかったことは、master/a.txtを見ながらdevelop/a.txtを編集したいということじゃないかと。

>>480
コードを見ながら修正するだけなら
別ブランチは不要

>>481
> 細かくcommitしながらコーディングしたいからでは？
参照するファイルはコミットしないだろ？

前のコードを開きながら、新しいコードを修正して
コミットしていけばいいだけ。

>>483
> 本当にやりたかったことは、master/a.txtを見ながらdevelop/a.txtを編集したいということじゃないかと。
本当にやりたかったことは、前のコミットのa.txtを見ながら、a.txtを修正することだろう。
developブランチを作るかは、ワークフローをどうするかの問題であって、
前のコミットを参照しながら修正するだけなら、別ブランチを作る必要はない。

大がかりに編集したいということだから、ブランチ切ってmasterに影響を与えたくないのでは。
まぁどうでもいいことだが。

developブランチ「俺はなぜ（略

>>486
だからmasterで直接修正をしていくのではなくて
ブランチを切って、そこからマージするというワークフロー自体は
問題ないんだよ。そして関係ない話なんだよ。

その場合はdevelopブランチで、古いa.txtを見ながらa.txtを修正していけばいい。
developブランチをmasterから切った時点では、developとmasterは完全に一緒なんだから、
当然developの過去のコミット＝masterの過去のコミット

過去のコミットのa.txtを見ながら、a.txtを修正すればいい。
という話を最初から言ってる。

ブランチを編集してmasterにマージすると
二本だった紐が一本にされてしまうのが気に入らないってのはあるな

既に>>471がおいてけぼりだと思いますっ

a.txtが何らかのバッチに組み込まれてる時はうまく行ってる状態を
すぐ参照する為にa.txtをいじりたくない場合はある
1.別フォルダにmasterをクローンしておく→フォルダが分かれてややこしくなる
2.develop/a.txtを編集しつつcheckoutでmasterとdevelopを切り替える→手間だがgit的には正解か？
3.develop/b.txtを編集する→とりあえずb.txtの履歴を保存しつつa.txtもそのまま

>>490
>>471に一番向いている回答は>>475だと思う。

開発ブランチにいるときにa.txtを使いたいときに困るじゃん

相手からプルリクエストを貰った
でもそのコードの一部を修正したい
そういう場合は貰ったコードをマージしたあとに、修正してコミットする流れでいいですか？

>>494
マージしても綺麗に動いているのであれば、
マージした後修正でもいい。

マージしたら壊れるならば、修正してからマージだ。

これ読むと良いよ

GitHubでの”Merge pull request”の弊害
http://postd.cc/merge-pull-request-considered-harmful/

自分のAを相手がforkしてBを作ってさらにB'にした
A -> B -> B'
|
A'

自分のもA'まで進んだときB'からプルリクエストが来たら
A’からQをfork
B'からPをfork
PからQにpull-request
QでマージしてQ'を作って動作確認
Q'が問題無ければそのままQ'をA'にpull-requestとマージ
問題があればQ'を編集してQ''を作ってA'にpull-requestしてマージ
A/A'を汚さなくて済む

>>496
もし数行のパッチだとしたら手間が掛かり過ぎ…
それにコントリビュータの名前が履歴に残らないよね？
>>495のリンク先のやり方がベストなんだろう
githubが同じやり方が出来るように対応して欲しいもんだ

>>495
良回答に良記事

>>496
A,B,P,Qがブランチ名のつもりなら、ブランチ名は人間が分かりやすくするためにつけてるに過ぎないということを意識すると過剰に複雑な手順にならないようにできるよ。
QはメンテナのローカルのA'のことだからすでに出来ている。PはB'のpull requestそのもののこと。一度出したpull requestはB'がB''に更新されてもB'を指すので別名を付けたのと同じことになる。
>>495のリンク先はgithubのマージ機能は使わずに自分のローカルワークツリーでマージ作業しましょうって意味だから、>>496の手順と同じことをhubを使ってやっている。

試しにgithubにプルリクしたあとにpullしましたが、
pullされたものに自分が修正したコミットをまとめられませんよね。

落としたプルリクのブランチに書き足してマージすれば相手のコミット使えるからそれで十分だろ

過去のリビジョンにcheckoutしてそのままコミットすると、それ以降のリビジョンが切り捨てられるって認識あってますか？

ちなみに、切り捨てられるっていうのは、どういう意味なんでしょうか

切り捨てられたリビジョンは、git上から存在しなくなるのでしょうか？
git reflogを見ると、そんな事はないような気がするのですが

>>502
あってない

>>503
>それ以降のリビジョンが切り捨てられる
ここが、あっていない所ですか？

>>504
過去のリビジョンにcheckoutした時点でカレントブランチが切り替わるから
その後コミットしても元のブランチの履歴には影響が無い

>>505
あざす

コミットしてない時、git add -pみたいな感じで一部の箇所のみresetして元に戻す方法ありませんか？

>>507
git checkout -p
必要に応じて
git checkout -p -- ファイルパス

git cloneすると 過去のコミット履歴が全部くるけど
コミットログは今年分だけあればいい
みたいにするにはどうしたらいいの？

>>509
shallow cloneを使うのです

シャロー クローン オボエタ アリガトウ

映画でおっぱい晒してる女優の名前だな

gitconfigのデフォルトの設定ってどうやって確認できますか？
初心者向けのgitconfigの設定をコピペして使ってたので、本来のデフォルトの設定はどうなっているのか確認したかったんです
例えば[push]のdefaultの値を知りたい。
git config --global -lとしても.gitconfigで設定したものしか表示されません。
どうやって調べるのか教えてください。

削除すればいいやん

いま編集しているファイルを
過去5番目のコミットにしたい場合ってどうやればいいんでしょうか？
直前だとgit commit --amendでできますが

commit してから
git rebase -i HEAD~5
で好きに並べ替える。

>>513
/etc

コミットメッセージの1行目以降の文って、
標準的なターミナルの表示文字数に合わせて、文の途中でも改行する？
それとも、まとまりのある文は1行にずらっと書き連ねる？

git log --oneline して大丈夫なように書く

>>518
一行目は50文字以下。
だから改行なんぞあるわけがない

>>520
1行目以降の話なんだが

>>520
すまん、**以降って**も含まれるんだっけ。

だったら、2行目以降の話ということで。

「以降」の意味を理解しないで書くなんてプログラマらしからぬ行動ですね

境界チェック

v2.7.0

1行目は50文字以内でコミットの内容を簡潔に書いて
2行目は空行で3行目から詳細な補足を書くのが作法だな

>>526
で、3行目からは、次のパラグラフまで改行しない？

俺今までずっとパラグラフ内では改行しないで書いてきたんだが、
そう言えばメールや2chでは適度に改行するよなと、ふと思ったもので。

git commitするとエディタにコメントされたメッセージが表示されますが
あれは削除したほうがいいですか？

>>527
いや改行は絶対するでしょ (ただし3行め以降は50文字よりは長くていいと思う)
見るときどこで改行されるか環境依存なのは良くない

俺が使ってる一番小さい画面のター
ミナル表示文字数が半角40文字ぐ
らいから38文字以内で改行してお
けばどの環境でも同じ箇所で改行
される

そうなのか。

Webブラウザのように改行箇所は環境に任せるのが得策だと思ってたが、
git のコメントはそうじゃないんだな。

適度に改行する事にするよ。
アドバイスありがとう。

いやいや530ネタでしょ

普通に読みにくいw
どっか縦読みなのかな。知らんけど

38文字の長さのモニターなんて無いから皆釣りだと分かっててスルーしてたのに

>>532
俺が >>531 で感謝したのは >>529 に対してだ。

529もどうなのかと

じゃあ結局どうなのよ

>>537
だいたい70文字程度で改行を入れているかな
つーかそもそも改行が必要な長文にならぬよう気を付けてる

git add -pで上から順番にaddするかどうか決めるのは量が多い場合にきついので
GUIからaddしたい部分を順番関係なく選択出来るツール教えてください

>>539
SourceTree

>>538
> つーかそもそも改行が必要な長文にならぬよう気を付けてる

マジか!?
70文字程度で改行を入れるスタンスで、そもそも改行が必要ないようにってことは、
ひとつの文を70文字以内に収めてるのか。

たとえば、あるデータベース swimming から全レコードを取ってきて一覧表示する機能を作ってコミットするとする。

コミットメッセージの1行目はまぁ簡単に

Display all records

とでもする（何を作ったのかを書く流儀もあるだろうが今は気にするな）。

で、２行目を空白にして、３行目に説明をもう少し詳しく書くとすると、

The program reads all records from the database swimming, and then outputs those to the standard output.

これで既にスペースや最後のピリオド含めて 104 文字だよ。

もしこの機能を実現するのにちょっと特殊なライブラリを使ってたりしたら、
俺なんかこの後に、To realize this, ... と、その説明も改行無しで加えちゃってたんだが。

70文字でひとつの文を収めるってそうとう厳しくないか？

コミット一覧を舐めるときにほしい情報以外はソースのコメントに書く
コメントに収まらないならドキュメント
コミットメッセージなんて流し読めるようにテンプレ化したほうがいい
長文の中からDiffを探すなんてやってられるか

コミットメッセージに実装したコードの説明を書いたらダメだよね
なんでそのコードを実装する必要があったのかとか書くべきであって

詳細まで残す必要があれば、本来ドキュメンテーション側に残すべき仕事だしね
個人的には、コメント自体は最小限であって欲しい派

ドキュメントに書くようなことではないけど、
コミットログを追う上で、書かれてると有益な情報の詳細を
コメントの3行目以降に残すわけね。
その一例が実装の必要性か。

なるほど、すごく参考になった。
自分のコメントを改めてみるよ。

みんな、ありがとう。

コミットメッセージの詳細が気になったらコメントやドキュメントのDiffを見ればわかるという流れがよい
アクセスポイントがコミットIDしかない場所にリーディングやメンテナンスに必要な情報を置くとか意味わからん
コミットメッセージに入れる情報はコミットログ上のコミットとしての自己記述と他に編集された差分情報のアウトラインや根拠・関連の参照先のオプションになる
GitHubだとIssueの操作コマンドも入る
コミットメッセージは過去になったスケジュール的なもので日記的に書き連ねたものにしてはならないと思っている

gitkってコミットできないんだね
sourcetreeってmacとwindowsでしか使えないんだね
クロスプラットフォームの定番GUIツールあったら教えて

>>541
あんまりコミットログに長文書きたくないからソースに書いてる

コミットログ見る時はだいたいソースの差分も横に見てるから
ジョースターさんに伝えたいメッセージもコメント文で残せる

>>548
ジョースターって何？

「git ジョースター」でググってもそれらしいものがヒットしないんだが。

ジョセフ・ジョースター？

>>547
git gui はあかんかった？

>>550
このコミットログを見て
うしろをふり向いたとき
おまえらは

>>551
知らんかったこれつかうわ
git-krakenも気になったが登録するの面倒だった

>>553
>git-krakenも気になった
なかなかイカしたUIやね

>>553
なかな見どころがあるでゲソ

>>549
「受け取ってください ジョースターさん」でググればいいと思うよ

src, lib, testsとディレクトリが3つあります
testsには著作権的にgithubで公開できないファイルも入っています
ローカルではtestsも含めて全部バージョン管理、リモートではtestsは除外

どうやれば良いでしょう?

>>557
githubでソースを公開するなら、testも第三者が実行できるように公開すべきだと思う。
著作権的に公開できないものって何？

mp3

submoduleというのを使ってみることにします。

private repositoryでやれよ。

解決方を提示できずに、言いがかりつけるだけなら黙ってて下さい。

は？private repositoryを使うのも解決法だろうが。

gothubという、お題を無視してるので、言いがかりに過ぎませんね。
それで済むなら質問する必要ない。くらいの思考はできないのですか?

gothub -> github

あらら、githubのことよく知らなかったのか。
githubのprivate repositoryだ。有料だが。

>>560
地獄を味わうがいい

頭悪いですねえ。
非公開なら質問する必要が無いことを理解できないのでしょうか。

>>568
GitHubのprivate repositoryでOKかどうかの判断すら、お前がまだ公開していない情報が必要。

つか、さっさとsubmoduleでやれよ。

>>567
たしかに地獄をみることになりそうなので、取やめです。

>>569
キミだけだよ。判断できない低脳は。

つか、著作権的に問題がないデータに差し替えるというのはできないのか？
そうしないと、どういう管理にするにせよ、testsを誰もgit cloneできないということになるのでは？

必要な条件が足りないから判断できないんでしょ。
判断出来ないのに無理して答えなくて良いよ。

文句しか言わないなこいつ。

>>557
著作権的に問題があるファイルを別管理すればいいだけ

>>574
公開したいに対して公開するなと、言いがかりしかつけられないアホは黙ってましょう。

>>575
ここの3の方法ですね。testsに下りなきゃならないのが面倒だけどしょうがないですね。
http://stackoverflow.com/questions/11058207/how-to-get-git-to-exclude-a-local-directory-from-push-to-remote-but-still-part

>>576
俺は外野だが>>557ではtests以外を公開したいなんて一言も書いてないぞ
testsには公開できないファイルがあるってだけの情報なら
プライベートリポジトリと提案するのは正解だろ
それとも気を利かして全て察しろとでも言いたいのかよ

自殺すれば全て解決

>>578
言い出しっぺどうぞ

うんこ味のカレーリポジトリとカレー味のうんこリポジトリとがある
カレーとうんこは限りなく似て異なる歴史を持つ

馬鹿: ニコイチにしてうんこ味のうんこにする
凡才: カレーへのコミットをフックしてうんこ成分だけをうんこへ投げる
山岡: このリポジトリはどっちもうんこだ、食べられないよ。

>>580
うんこだと意味不明なので
「高級」に置き換えてみたよ。

高級味カレーリポジトリとカレー味の高級リポジトリとがある
カレーと高級は限りなく似て異なる歴史を持つ

馬鹿: ニコイチにして高級味のうんこにする
凡才: カレーへのコミットをフックして高級成分だけを高級へ投げる
山岡: このリポジトリはどっちも高級だ、食べられないよ。

訂正

うんこだと意味不明なので
「高級」に置き換えてみたよ。

高級味カレーリポジトリとカレー味の高級リポジトリとがある
カレーと高級は限りなく似て異なる歴史を持つ

馬鹿: ニコイチにして高級味の高級にする
凡才: カレーへのコミットをフックして高級成分だけを高級へ投げる
山岡: このリポジトリはどっちも高級だ、食べられないよ。

ついでに、キャビアバージョンも作ってみたよ

キャビア味のカレーリポジトリとカレー味のキャビアリポジトリとがある
カレーとキャビアは限りなく似て異なる歴史を持つ

馬鹿: ニコイチにしてキャビア味のキャビアにする
凡才: カレーへのコミットをフックしてキャビア成分だけをキャビアへ投げる
山岡: このリポジトリはどっちもキャビアだ、食べられないよ。

いまいち面白くなかったので
シチューにしてみるよ

シチュー味のカレーリポジトリとカレー味のシチューリポジトリとがある
カレーとシチューは限りなく似て異なる歴史を持つ

馬鹿: ニコイチにしてシチュー味のシチューにする
凡才: カレーへのコミットをフックしてシチュー成分だけをシチューへ投げる
山岡: このリポジトリはどっちもシチューだ、食べられないよ。


山岡はシチューを食べられないということか？

三銃士を連れてくる所長まだ？

>>577
ああ、アホがまたわいてきた。
githubでリポジトリ作る時にpublic/privateの選択するんだよ。
privateを選択しなかった理由があるって事だ。

お題が明らかに間違ってるならともかく、お題に言いがかりつけてまで回答しなくて良いんだよ。

スレ違い
こっちに行け

OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/

>>294=>>557だろ
お前は二度と書き込むな

>>586
だから>>557見てprivateの選択をしなかった理由とかどこから出てくんだよｗ
お前こそあやふやな質問を一生懸命正当化しなくていいよ
とにかく>>561への>>562の返答はマジでないよ

>>587-588
とっても、頭悪いね。
private/publicの使い分けなら、github固有の話題だけどpublicを選択したんだから
github固有の話題じゃないって事くらいわからないのか?

>>589
頭悪すぎ。
githubを良く知らないなら「privateを選択しなかった」経緯がわからないだろうが、
>>566だからね。とってもよく知ってるという事だし。

> とにかく>>561への>>562の返答はマジでないよ
>>561だけじゃなくて>>558から続いてるからね。
「公開すべき」、「そのファイルはなんだ?」言いがかり付けたいだけだろ。

>>578
HDD/SSDはどう処分する？

>>562
言いがかりて
あなた病んでるよ

>>592
>>588,562で言いがかりつけられたと感じられないキミはかなり鈍感だと思う、ある意味幸せな人。

かわいそうな奴だな

これからしばらくGitHubでmp3関連のプロジェクトが登録されるか監視しようぜ

頭弱いね。
回答には不要な「そのファイルはなんだ?」って聞いてきてる時点で、言いがかりを疑ってるので、正直に答えるわけないじゃん。
ま、監視するならご自由にどーぞ。

読み飛ばしてたけど、最終的にignoreするってことか

> ローカルではtestsも含めて全部バージョン管理、リモートではtestsは除外
言ってることが違うじゃんw

色々と後出しが苦しいなｗ

>>593
落ち着けよw
レス番間違ってるぞ

>>597
プロジェクトリポジトリではtests/をignoreして、testsを別リポジトリにするしかないらしいのでそうしたけど、
当初の目標の
> ローカルではtestsも含めて全部バージョン管理、リモートではtestsは除外
になってるでしょ。

「testsも公開しろ」、「全部非公開にしろ」、「公開できるようmp3自作しろ」
言いがかりじゃなくて真剣に回答してたならアホとしか評価できんわ。

>>596
回答に不要ならわざわざ「著作権的に」とか書かなければいいのに

>>600
> testsも公開しろ
→ 妥当な意見
> 全部非公開にしろ
→ 妥当な意見
> 公開できるようmp3自作しろ
→ 妥当な意見
だと俺は思うがね
まぁ、gitのこともGitHubのこともテストのことも良くわかってないお前とは意見が合わないだろうが

お前ら何くだらんことやってるんだ？

俺が>>575で別管理しろっていうのは、
単にテスト専用のリポジトリを作れってだけだ。
submoduleとか使ってメインのリポジトリと関連付ける必要もない。

単にtests/hogeというディレクトリがあれば
hogeテストを、追加でやるだけの話だろうって
事を言ってるんだが。

>>600
お前の好きにしろ
そして二度と書き込むな

>>602
わあ、マジで回答してたつもりだったのか。
知的障害者と知らなかったので、言いがかりと疑って失礼な事をしたな。

>>603
ん? >>576で引用した
3 You could tell git to ignore the subfolder, than create your java-cli repository there and just the two without any interaction.
の事でしょ? これやってるんだけど違うの?
この方法だとtestsに下りないとgitが操作できなくて面倒なので、これを回避できる技があるなら教えてほしい。

>>604
好きにして、後はお前ともう1人のバカをからかって遊ぶよ。

> この方法だとtestsに下りないとgitが操作できなくて面倒なので、これを回避できる技があるなら教えてほしい。
ないよバーカ

>>590
> githubを良く知らないなら「privateを選択しなかった」経緯がわからないだろうが、
> >>566だからね。とってもよく知ってるという事だし。
有料じゃ駄目なんて一言も書いて無いじゃんｗ
はい、また後出しの言い訳

他にも楽な方法提案できるけど
コイツの態度が気に食わないから言わない

>>557でtests以外はバージョン管理はするが公開すると書いてないから
プライベートリポジトリとか提案が出てるのに突然>>562でブチギレ

なぜ>>562でtests以外は公開したいから解決にならないと一言言えないんだろうか？
突然ののしるってマジでアレなんだろうね

やべえやつやｗｗ

自殺が、最適

https://quitter.se/notice/4425126

https://quitter.se/notice/4422376

今使ってるgitのバージョンは1.7.1なんだけど、自分一人だけ2.7.0とかをビルドして使うと問題あるかな？
例えば、新しい機能を使ったローカルコミットをpushすると、古いバージョンだとpullできないとか、
自分がgit initしたリポジトリは、古いバージョンだとcloneできないとか。

質問です
・gitでリポジトリに保存したときタイムスタンプや属性も保存できますか？

・バイナリーが重複していた場合どうなりますか？

・リモートリポジトリはサーバ上に作成できますか？またサーバが故障した場合個人のローカルリポジトリをリモートリポジトリとして使うことはできますか？

複数の質問を同時にして申し訳ありませんが答えてもらえると幸いです
あと読んだ方がいいサイトでもいいのでよろしくお願いします

いいえ
どうも
はい

タイムスタンプが保持できるのってsvnだけ？

>>617
すごくわかりやすくありがとうございます

タイムスタンプはコミットした日時から判別できる。
だけどコミットした日時はチェックアウトした
ソースコードに反映させてはならない。

なぜならビルドツールが日時を元にビルドするかどうかを決めているから。
最新のコードでビルドした後に、古いソースコードをチェックアウトしたときに
日付まで古くなったらビルドされなくなる。

gitは実行属性は保存される。（ついでにシンボリックリンクも）

なので>>617の一番目は間違い

>>621
ナイスフォロー

>>620
ビルドする言語ならそれでいいだろうけどな。

>>623
ビルドする言語では問題が出る。
ビルドしない言語は元から問題がないので
「ビルドする言語ならそれでいい」という言い方はおかしい

逆に「タイムスタンプを保持するのは、ビルドしない
言語ならそれでいいだろうけどな」と言うべきだ


タイムスタンプはチェックアウト（正確にはチェックアウトで変更される場合）
に最新になるべきで、そうなっていればどちらでも問題はない。


で、ありがちなのが、ソースコード管理ツールで、ソースコード以外の
エクセルとかを管理して、タイムスタンプを保持して欲しいって言う奴がいるんだよなｗ
ソースコード管理ツールの間違った使い方をしているのが原因。

たまたまその方が便利だからそういう仕様になっているだけで

ファイルの更新日時をリポジトリに保存する事が間違っている

という事では断じてない

>>625
えとな。gitにはファイルの更新日時どころか
行ごとの更新日時が記録されてるの。
git blameで見たらよく分かるよ？

その上で、ファイル自体の更新日付は
チェックアウトなどで変更があった時に更新される
仕様になってるの。

最初からそう言ってるんだが。
> タイムスタンプはコミットした日時から判別できる。

行ごとの更新日時なんて記録してたのか知らなかったわ
blob同士のdiff取ってるだけだと思ってた

>>627
行ごとにコミットIDがわかる。
だからコミットした日付から判断できる。

>>627
その皮肉は>>626には伝わらなかったようだぞ

更新日時とコミットした日時を混同しとる。

>>629
わかってないのはお前だよ

>>630
> 更新日時とコミットした日時を混同しとる。
それは最初に言い出したやつの話だな。

ファイルの更新日時は、ファイルが変更された時だから
チェックアウトで更新しても、変わるべきもの。

「タイムスタンプはコミットした日時から判別」ってどうやんの？無理じゃね？
git でファイルの更新日時なんかファイル単位でも行単位でも記録されてなくね？

>>630
>>632には伝わらなかったようだぞ

>>634
だからわかってないのはお前だってｗ

>>633
ほらよ。行ごとの更新日時

1万行を超えるファイルXがあり
コミットツリー(歴史)を辿ると１万回ほど変更を加えたコミットがあったとすると
それだけ大量のdiffをするとなるとそんじょそこらのPCじゃ１日では足りない
コミット自体にdiffで得られる変更のあったファイルの変更箇所の行番号だけでも保存しておけば行番号の整合性を取るという高速な処理でblameが生成できる

>>635
それ、行ごとの最終変更コミットの日時じゃね？

>>635
夜中に笑わかすなｗ
腹痛いｗ

gitがあまりにも凄すぎて、gitだけが唯一完全なvcsの実装だと信じてしまった ID:X0JkwFym
生まれたてのヒヨコのようなものだが、こういう間違いは誰にでもあるｗ

>>637
> 最終変更コミットの日時

だからそれが最新変更日時だって

>>640
きのう変更したファイルを今日コミットしたら、リポジトリに記録される日時は今日じゃね？
それって最終変更日時じゃなくね？

ひっこみつかなくなって珍論を生み出したｗ

そもそも論として使い方が間違ってるんやろうな

>>641
リポジトリにコミットした日が変更日だよ。
変更が確定した日なんだから。
それとファイルの変更日時とは別

俺の定義が正しい君はもういいよ

人それぞれ定義は違う君はどうでもいいよｗ

釈迦に説法するマンお疲れッス

>>639
ID:n7YAZoBS=ID:X0JkwFymの純朴さに対して
ID:ntutQCMGの優しさと
ID:unNXfSByの腹黒さよ

開発中に「これ大至急修正を頼む！」って言われた場合どうしたらいいのか教えてください
ただし、いま開発中の内容を履歴に残したくはありません
いま開発中のファイルと修正を頼まれたファイルは同じです。
$a = 1を$a = 0に修正するだけです

>>649
git stash

もし $a = 1 前後の行を触ってなければ git add -p も手早

SourceTreeの行単位のステージングはすげえ便利だぞ

行単位ステージングって git add -i だっけ？

コマンドラインでやるときは、
git add -pして
目的の部分周辺をsでなるべく
小さくした後
eで一行だけ有効にしてた

git stashとadd -pどちらでもできそうですね
あと$a = 0にした修正を今開発中の内容に含める場合はどうしたらいいんでしょうか？
今回のように1文字変更するぐらいなら手動で書き換えればいいんですが、
多い時はコピペするのは危険なので

一時ブランチ作ってコミットして退避させれ
スタッシュは戻すときにコンフリクト出るとめんどくさい

そうそう。
gitはsquashなりamendなりで後から履歴の変更が出来るんだから
ローカルのコミットは遠慮なくすればいいんだぜ。

>>655
「今開発中」のブランチのベースにcherry-pick

状況が正確にわかんないけどrebaseのほうが綺麗な履歴になるんじゃないの

rebase -i して pick で差し込む
って同じやんかーい

>>607
オメーには聞いてねーよ。バーカ。

>>608
バーカ
ファンタジー系ラノベのギルドテンプレのザコモブ

>>609
オメーには聞いてねー
回答する能力無いことは判明してるからな

githubで公開したからmp3プロジェクト監視しろよ
バーカ

>>659
rebaseという文化が嫌い。 甘えですよあんなの

漢は黙ってCVS

CSV、ちょっと複雑なデータならJSONだな

せめてSVN

>>665
なんでもかんでもrebase、履歴が綺麗になるのが一番、とは思わないけど、
なんでもかんでもrebase禁止ってのもまたイマイチな考え方だと思うけど

あんま使いこなしてないからかもしれないけど、bisectなりなんなりでエンバグしたコミットを特定するのがマージだとわかりにくくなるケースない？
ちなみにたまにしかrebaseは使わない

>>665
何いってんのお前？

間違ったものを正しく修正することの何が悪いのか。

typo修正だらけのコミットログが透けて見えるようだ

git cloneしたときにmasterブランチしかクローンされないんですが
他のブランチも一緒にクローン出来ませんか？
--no-single-branchって付けたらいいのかなと思いましたがmasterブランチしか取れませんでした

ローカルブランチが出来てないだけと見た。

気づかないとは古いgitを使ってる可能性もあるな
1.8ぐらいだったから、それ以上を使えよ。

存在しないリポジトリをcloneするとusernameとpasswordの入力を求められるんですけど
こういう場合はエラーにする方法ありませんか？

>>675
それはサーバー側の設定次第じゃないの？

アカウントでアクセス制限してるサーバでリポジトリが存在するかどうかを
認証無しで知られてしまう、という設定か

ﾜﾛﾀ

それを不便に感じるほどやらかしてるのか、
たった一度でもう我慢ならんのか。

> 存在しないリポジトリをcloneするとusernameとpasswordの入力を求められるんですけど
> こういう場合はエラーにする方法ありませんか？

この動作で困る例が思いつかない。

>>680
想像力が貧困やね

それはお互い様だと思う

>>681
ほう！ならばどういう時か
例を言ってくれていいんだよ！

君にとっては、本当に思いついたという
証拠にもなるしね！

URL手打ちでリポジトリ名のtypoとかじゃねーの？知らんけど

入力させられるのにムカつくのは好きにすれば良いが、
それで何か困るのか？って話だ。

でたらCTRL-Cを押せばいいだけだしな。

バッチ処理でも組みたいとかなんじゃないの
バッチの引数でポジトリのURL渡して自動でcloneして色々何かの処理を自動でこなして終了、みたいな
んでこのバッチ処理スクリプトを複数のマシン、複数の人間で使いたいとか
そんなとこじゃね？

>>687
デバックしろよ。

687が？
debackって何？

>>687
すいませんそういうことです

あなた680じゃなくて675でしょ？
ほい

http://git-scm.com/docs/gitcredentials

>>691
いろんな環境で使えるようにしたいので、出来ればconfigには触りたくないのですが
コマンドの引数だけで出来る方法はないですかね？

git clone --recursiveってしたらsubmoduleも全部ダウンロードしてくれるじゃないですか
こうやってcloneしたときはpullはどうしたらいいですか？
git pull
git submodule update --init --recursive
って2回に分けてコマンド実行しないとダメですか？
1回でpullしてsubmoduleも更新するやり方ありますか？

>>693
GIT_ASKPASS がそれじゃね？

>>695
GIT_ASKPASSに何の値を設定したらいいんですか？
試しにexport GIT_ASKPASS=NONEしたら
＞error: cannot run 0: そのようなファイルやディレクトリはありません
ってエラーが出た後にusernameとpasswordを入力させられます

ああ、すいません680じゃなくて675です
680さん失礼しました

>>696
パスワード入力用の外部コマンドを指定するためのものらしい
/bin/false 指定してみたら？

git使うときmac、windowsでUTF8、SJISで困ってるんだけど
変換勝手にしてくれたりする方法あります？

windowsでutf8引っ張ってきた時のコンパイルで死にます

それぞれの環境は？
UTF8でWindowsで困ってないけどな
コミットする時点で変換するトリガが無いかってことかな

Windows版gitは改行の面倒は見てくれるが文字コードは何もしない
同じくutf8で別に困る事ないけどな

今思い出したが多分VS使ってんならBOM入ってないとutf8のファイルをutf8と認識せずおかしなエラーになるな

>>698
指定したけど入力を催促されました

>>699
文字コードを勝手に変換するほうが困ることになる。

同じソースコードなのに、そこに埋め込まれた
文字コードが違うってことになるんだぞ？
だから同じ理由で改行コードの変換もしない設定するのが基本。

ソースコードの文字コードと改行コードは、どこでも同じものにするべきで、
まともなテキストエディタを使えばいいだけ。

>>704
そりゃ違う
ソースコードが改行に依存してる事の方が問題だ
もし改行に依存してたらそれはデータとしてバイナリ扱いにする必要がある
文字列に改行を含める場合は前後の文字列を実行時にプラットホーム固有の
改行で結合するまでやらないとプラットホーム非依存にはならない

俺はWindowsとLinuxで改行コードをgitの自動変換ありで使ってるけど何も問題無い
逆に問題が出る場合はどこかに非依存な部分があるというだけ

>>705
いや少し違った
コンパイルする言語の場合は改行コードはコンパイル時に決めれば問題なかったな
スクリプトの類は実行時に判定する必要はあるけど

>>705
言語によって適切な改行コードは違うんだよ。
例えばシャルスクリプトはLF限定。

このテキストのデータファイルはLFであることを
前提にしているというコードというのもあるし、
LF と CR LF ではファイルサイズまで変わってしまう。

改行コードを統一することに意味はあるが
環境ごとにばらばらにする意味は無い。

環境ごとにばらばらにしたほうがいいという理由があるかい？

>>707
> 例えばシャルスクリプトはLF限定。
LinuxでチェックアウトすればLFなんだから何か問題あるのか？
Windowsでシェルスクリプト動かすつもりかよ…物好きだな
例えそうだとしてもWindows版bashはCRLFで問題なく動く

LF前提のパーサーなんて幾らなんでも糞過ぎだろ
あとファイルサイズが変わって何の問題があるんだ？
gitは改行コードが変わっても適切に差分を管理するし問題ない

> 環境ごとにばらばらにしたほうがいいという理由があるかい？
お前みたいな奴はLinuxオンリーでやれよ
「わざわざ」Windowsでgitを使う理由をよく考えろ

お前は多分WindowsとLinuxでgitが改行を変換する使い方をした事がないっぽいな
Linuxサーバで動かすシェルスクリプトをWindowsでチェックアウトして
そのままLinuxサーバにアップしようとしてるのが目に見える

>>708
目に見えるっておかしいな、目に浮かぶか…もう寝る

>>708
言い訳はいいんだけど、

統一しない理由はなに？

> 「わざわざ」Windowsでgitを使う理由をよく考えろ
それをお前に聞いているんだが、
その理由を言わないよね？

> Linuxサーバで動かすシェルスクリプトをWindowsでチェックアウトして
> そのままLinuxサーバにアップしようとしてるのが目に見える

こういう事例も、統一した方がいい理由の一つですよね。

他にもLinuxサーバーのソースコードをWindowsで編集することもある。
その逆もあるだろうな。

いちいち場合毎に改行コードを使い分ける理由がないんだから、
統一した方がいい。

ヒアドキュメントとかもあるな。
ソースコードに埋め込まれた改行コードが変わると
問題が起きる場合。

ハイ、ハイ！

>>710
統一するコストに比べてメリットが少ないからだろ。

>>715
統一するコストってなに？

ソースコードなんて所詮プログラムの内部仕様なわけで、
内部仕様までプラットフォームごとの違いを吸収するように作る必要はないんだよ。
テキストファイルのように入出力の部分で吸収させればいいだけ。

でもヒアドキュメントのようにソースコードに含まれる改行コードが
変わってしまったらプログラム内部のデータが変わってしまう。

>>711
つうかそんな事いちいち聞くなよ
プログラマじゃない人がどんなエディタ(メモ帳含む)で編集しても
問題が起こらないからだろ
なぜかLFで開いてもCRLFで保存するエディタとかもあるんだよ(そういう設定にしたのかもしれんけど)

あと、Linuxでチェックアウトすれば全部LFになるのに何の問題があるのか逆に聞きたいよ
相互運用した事もないのに脊髄反射で反論すんなよ

つか元々の質問の奴はどうなったんだｗ

まぁ個人的には今たまたま問題出なくてもどこでいつ問題起きるかわからなくて気持ち悪いから固定するけど
どうしてもクソな環境に合わせないといけないならほんとしょうがなくだと思う

分からないからとか気持ち悪いとかプログラマがいう事じゃないよ
結局自分が分からない事やってる奴は頭おかしい理論で反論してるだけなんだよな

なんでこいつらファイルの中身の文字コード前提で話し進めてるの？
なんで文字コードじゃなくて改行コードの話に脱線してるの？
アホばかりなの？

>>717
> あと、Linuxでチェックアウトすれば全部LFになるのに何の問題があるのか逆に聞きたいよ

ソースコードの中身にCR LF と書いていて
CR LFで扱うコードが正しく動かないから。

同様にソースコードではないCR LF前提のテキストファイルの
データ形式（例えば電子メール）が変わってしまうから。

>>721
>>705を読め
> もし改行に依存してたらそれはデータとしてバイナリ扱いにする必要がある
> 文字列に改行を含める場合は前後の文字列を実行時にプラットホーム固有の
> 改行で結合するまでやらないとプラットホーム非依存にはならない

なので、ソースコードにCRLFを直接書くなんて完全にバグ
改行コードが変わってまずいメールをgitに入れるならデータ扱いでバイナリにする必要がある
以上

> なので、ソースコードにCRLFを直接書くなんて完全にバグ

ヒアドキュメントを使えば必然的にCR LFになるって言ってるだろうが

>>721
いや違う…
> ソースコードの中身にCR LF と書いていて
もはや的外れな事言ってるじゃないかよ…
例えばCのソース内に"\r\n"って書いてそれをgitが変換するわけじゃないっての

>>719
分からないってのは技術的な話じゃなくて政治的な話だよ
そもそも何でいまだに統一しないとか今後も永久に同じ仕様で行くって企業の行動を予知できるのか

そういう余計なことに気を使うのが気持ち悪いって言ってるだけだ
逆に環境によって改行コードを強制されないといけないクソ環境の合理的説明を聞きたいわ

>>724
> "\r\n"って書いて

お前が今このスレではじめて出した言葉だよ。
だ〜れも、\r\n なんてことは言ってない。

>>723
ヒアドキュメントの改行が「Windowsで」CRLFになっても問題ないことがほとんどだ
むしろその方がいいだろう

ようするにLinuxサーバーで動かすソースをWindowsでチェックアウトして
それをLinuxサーバーに直接アップしたいって事だろ？
そんな事したい奴の話はどうでもいい

>>725
政治的な話ならどうでもいい
そんな事いいだしたらsvnを強制されても合理的な理由になる

>>726
じゃあ>>724は無視していいよ>>722でちゃんと返答してんだから

> ヒアドキュメントの改行が「Windowsで」CRLFになっても問題ないことがほとんどだ
ほとんどだって言ってる時点であるって言ってるのと同じじゃねーかｗ

そのほとんどっていうのが問題なんだが。
絶対問題になるのなら対処するだろうが、
だいたい問題にならないけど、特別な場合だけ問題になるっていうのが
「特定の条件でのみ発生するバグを見逃す」ことにつながるんだが。

改行コードはプラットフォームとは無関係に統一しておくだけで
解決する問題を、なぜわざわざ増やす？

>>727
> ようするにLinuxサーバーで動かすソースをWindowsでチェックアウトして
> それをLinuxサーバーに直接アップしたいって事だろ？

なんでそれがだめなんでしょうか？ｗ
たったそれだけのことで問題になるから、
改行コードの自動変換はやめるべきことですよね？

>>728
おまえみたいな決め付けで行動するやつがいるからコードがうんこになるんだよｗ
何がプログラマの言うことじゃない（ｷﾘｯだよ

>>730
そんな突っこみいらないよ
常にLFにすれば「絶対」問題ないといえるんだな？

だからWindowsでテキストを扱うにはLF前提の方が問題が出やすいと言ってんだ
特にCRLFで保存するなといっても意味の分からん人もいる
一人でとかプログラマのみで開発してるなら強制すればいいだろ

強制しなくてもそのプラットフォームで自然な改行で問題ないように対応されてる方が問題が出ない

shebangのケツにCRがついてbad interpreter喰らって泣きつくバカの尻拭いさせられるぐらいの問題

>>731
それこそ糞みたいな開発環境だな
改行以前の問題だからどうしようとどうでもいいよ

>>733
> だからWindowsでテキストを扱うにはLF前提の方が問題が出やすいと言ってんだ
LF前提とか言ってないしｗ
バッチファイルならCR LFだろうよ。

自動変換するなってだけで、改行コードが環境によって変わらなければそれでいい。

> だからWindowsでテキストを扱うにはLF前提の方が問題が出やすいと言ってんだ
> 特にCRLFで保存するなといっても意味の分からん人もいる

意味がわからん人を教育すればいい。
逆に、意味がわからん人が、環境によって勝手に変わる動作を
想定するわけがだだろ。
お前の主張は破綻してるんだよ。

お前が言ってる問題って、テキストエディタの設定であっさり解決する問題じゃねーか。

俺が言ってる問題は、同じソースコードなのに環境によってコードの中身が書き換えられ
意図せずにソフトウェアの動きが変わってしまってバグの元になるって話をしてるんだが。

メモ帳がLFをまともに扱えないから、LF前提にしとくとメモ帳使って先頭にBOM入っちゃう事故を回避しやすそう

>>735
おや？何か反論してくるかと思いましたが、
何も言い返せずに終わりましたねｗ

>>737
改行コードを統一するのが嫌って言ってる奴は、
メモ帳をどうしても使いたいんだろうなぁｗ

>>734
> shebangのケツにCRがついてbad interpreter喰らって泣きつくバカの尻拭いさせられるぐらいの問題

実際にあるねそれｗ

Windowsでもcygwinとかmsysgitとかでシェルスクリプト
動かすことあるからね。

>>736
> 自動変換するなってだけで、改行コードが環境によって変わらなければそれでいい。
お前は俺と同じ主張をしてるぞ…
Linuxでチェックアウト→LF
Windowsでチェックアウト→CRLF
なんだからその通りだよ

> 俺が言ってる問題は、同じソースコードなのに環境によってコードの中身が書き換えられ
> 意図せずにソフトウェアの動きが変わってしまってバグの元になるって話をしてるんだが。
俺はソースコードの改行が変わったことでバグるプログラムに問題あるといってんだ
それって実行環境と読み込むデータ自体の改行も決め打ちだよな？
そうじゃないと駄目だと声高に主張するならそうすればいいじゃん

>>740
WindowsだとCRLFでシェルスクリプトは動く
ちなみにCRLFであってケツにCRが付いてるわけじゃないからな
エディタで変な読み込まれ方をするとCRがケツについてるように見えてるだけだろ

#!/usr/bin/perl
で始まるのを
#!/usr/bin/perl --
にシコシコ書き換えて回るのは大変だなぁ

>>742
> ちなみにCRLFであってケツにCRが付いてるわけじゃないからな
shebangを解釈するexecve(2)にとってはケツにCRが付いてると思ったんだ

>>740
つうかケツにCRとか言っちゃってるレベルの奴だったのか…

>>741
> Linuxでチェックアウト→LF
> Windowsでチェックアウト→CRLF
> なんだからその通りだよ

ぜんぜん違うだろ。

テキストファイルにLFで書いたもの→どこでチェックアウトしてもLF
テキストファイルにCRLFで書いたもの→どこでチェックアウトしてもCRLF

勝手に変わったらいけない。

>>745
> 勝手に変わったらいけない。
だからどういけないのか言えよ…

どうせ糞みたいな制約だらけのテキストパーサ自慢なんだろ
そしてデザイナとか上司が知らずにWindows上でCRLFで保存しようモンなら
血相変えてなんでCRLFで保存したんだと怒鳴り込む姿が目に浮かぶ

>742
> WindowsだとCRLFでシェルスクリプトは動く

今、メモ帳で書いたこのコードを、cygwinで実行したら
見事にエラー出たけど？ｗ
> #!/bin/sh
>
> echo ok

./test.sh
: not found2: ./test.sh:
ok

信じられないならdiffの結果見せてやろうか？

$ diff -u test.sh test2.sh
--- test.sh 2016-01-29 11:31:55.182889600 +0900
+++ test2.sh 2016-01-29 11:28:59.888609900 +0900
@@ -1,4 +1,4 @@
-#!/bin/sh
-
-echo ok
-
+#!/bin/sh
+
+echo ok
+

もちろん、改行コードの違いを無視する
diff -ub test.sh test2.sh なら差は出ない。

仕様としては改行コードは○○って決まってるけど各自の作業は自由ってのが
もはや仕様としてCRでもLFでもCRLFでも決まってないってところまで行く勢いだなｗ

>>746
> だからどういけないのか言えよ…

何度も言ってるだろ。具体的な事例出してバグになるって。

それよりかお前が言えよ。
お前は、改行コードが勝手に困っても困らないはずだ。と言ってるだけで
改行コードが勝手に変わったほうが良いとは言ってないよな？

困る事例はお前自身だって言ってるわけで、
勝手に変わったほうがいい理由がないなら、
変えない方がいい。

>>747
> 今、メモ帳で書いたこのコードを、cygwinで実行したら
> 見事にエラー出たけど？ｗ

cygwinはmount時にテキストモードとかバイナリモードとかあるんだよ。
そのあたりの設定がうまいこといってねえんだよ、きっと


一時期のbashにあった改行コードがCR+LFのシェルスクリプト中に $() や & があると
おかしくなる問題はbash-4.3.42-4 にしとけばいいんだよ、たぶん。
https://sourceware.org/ml/cygwin/2015-09/msg00439.html

>>746は
> そしてデザイナとか上司が知らずにWindows上でCRLFで保存しようモンなら
> 血相変えてなんでCRLFで保存したんだと怒鳴り込む姿が目に浮かぶ

デザイナとか上司が知らずにShiftJISで保存しても
動くように作れって怒鳴りこみそうｗ


俺がどうするか？って怒鳴りこまないよ。
冷静に説明して修正するだけ。

>>747
cygwinをインストールした時に改行コードをどうするか聞かれただろ？
どうした？

>>748
だからちゃんと理解しろよ
Windowsで保存する時はCRLFだがLinuxでチェックアウトすればLFでチェックアウト出来るんだから
仕様としてはLFでいいんだよ

>>750
> cygwinはmount時にテキストモードとかバイナリモードとかあるんだよ。
> そのあたりの設定がうまいこといってねえんだよ、きっと

設定は何もしていない。インストール時のデフォルトだ。

>>752
> cygwinをインストールした時に改行コードをどうするか聞かれただろ？

デフォルトだ。

何かを得れば何かを失う。人生とはそんなものだ。
状況に応じて使うか使わないかを決めるといい。

>>752
> Windowsで保存する時はCRLFだがLinuxでチェックアウトすればLFでチェックアウト出来るんだから

お前ファイル共有って知ってる？

チェックアウトだけが、ソースコードを受け渡しする方法じゃねぇんだよ。

なに余計な複雑度を組み込んでるんだ？
改行コードを統一するだけで解決する問題だって言ってるだろ。
お前は解決する方法を一つも言ってない。
困る事例を無視して困らないはずだって言ってるだけ。

>>751
SJISでも動くようにするのも場合によっては必要だろ
さすがに文字コード変えて保存する事例はなかったが頻発するなら必要な事だ
あらゆる制約はなくす方向で行かないと
説明する人数が一人ぐらいならいいけどもう少し人数が居たら説明なんてしてられない

>>757
> SJISでも動くようにするのも場合によっては必要だろ

必要な時"だけ"、やれ、な？

やらなくていもいいことは、やらないようにしろ。
改行コードの問題も同じだ。

>>757
> 説明する人数が一人ぐらいならいいけどもう少し人数が居たら説明なんてしてられない

>>757の所がウェブ会社だったら、
HTMLが全部ShiftJISなのに、metaにUTF-8って書いていそうｗ

まあ、説明なんてしてられない。ならそうなるしかないわなｗ

>>756
> チェックアウトだけが、ソースコードを受け渡しする方法じゃねぇんだよ。
はいダウト
そういう事するなら勝手にやってくれよ

>>760
何がダウンと何だ？ｗ

こうやってすぐ逃げる。

>>758
必要だからやってる、それだけの事

>>759
ちなみに文字コードはgitが変換するわけじゃないからLinuxでチェックアウトする時に
スクリプトかましてutf8にする必要がある
重要なのはLinuxでチェックアウトした時にLFでutf8になればいいだけ

>>761
ダウンｗｗｗダウンってなんだよｗ

なるほどねｗ

http://hiromasaya.web.fc2.com/Cygwin/crlf.html

Cygwinの改行コードはデフォルトでUNIX互換(LF:0x02)になっている。
これは特に問題はない。

もしDOS互換の改行コード(CR LF:0x080x02)のテキストファイルがあっても通常問題は発生しない。
エディタやコマンドが対応して正常に動作するからだ。
ただし例外として、bash ver4系シェルスクリプトでは、DOS互換の改行コードはエラーになる。

問題となるのは、Cygwinの gcc3/gcc4コンパイラが出力するテキストの改行コードで、
DOS互換の改行コード(CR LF:0x080x02)が出力されてしまうこと。なぜこうなっているのか不明だが、今のところgccのオプションでは回避できない様だ。

これは、Cygwinで自作したC/C++アプリの出力テキストファイルは、SolarisやLinuxに移動するとDOS互換改行コードのファイルが混じり込むことになるという問題が発生する。

これは大きな問題ではないが、留意しておく必要がある。

>>762
> 必要だからやってる、それだけの事

必要な理由を言え。

>>759
> ちなみに文字コードはgitが変換するわけじゃないからLinuxでチェックアウトする時に
> スクリプトかましてutf8にする必要がある
> 重要なのはLinuxでチェックアウトした時にLFでutf8になればいいだけ

何のためにそんなことしてるの？ｗ

文字コードと改行コードを統一するだけで解決しない問題なんですか？ｗ

>>761
ダウトのtypoじゃね？

とりあえずgit archiveとかgit checkout-indexとかやって受け渡すことはできるね
チェックアウトせんでも。

まぁ馬鹿の介護で非効率なことをすることが一流のプログラマや一流の企業の条件ってならもうしょうがないｗ

>>765
だからデザイナとか上司がWindows上で…ってどこかで書いたよ

> 何のためにそんなことしてるの？ｗ
お前マジで頭悪いだろ…>>757でそんな事はなかったがやる場合はって話だろ
お前さっきから変な日本語を書き込んでるけど日本人か？

https://github.com/vim-jp/vital.vim/issues/102

> ちなみにGitHub for Windowsにはマルチバイト文字が含まれているファイルだとcrlf->lf変換がされないというバグがあります。
> やっとライブラリが更新されて直ったようです。

やっぱり改行コードの自動変換はろくなことないね。


http://d.hatena.ne.jp/couichi/20110207/1297101115
> マニュアルの core.safecrlf の項目を翻訳してみた。
> git-config(1)
> CRLF の変換は、稀にとは言えデータ破損の危険性を伴います。
> しかし、誤ってテキストファイルと分類されたバイナリファイルの場合、変換はデータを破損するかもしれません。

やっぱり改行コードの自動変換はろくなことないね。

>>767
プログラマ仕事は素晴らしいコードを書くことだと悦に入ってる姿が目に浮かぶ
プログラマなんて奴隷だろ
あらゆる要求や仕様にNOと言わない奴が有能なプログラマだ
当然YESというのは簡単だが出来ないのにYES言う奴は一番最低だ

>>768
> だからデザイナとか上司がWindows上で…ってどこかで書いたよ

だから、デザイナや上司がWindows上でHTMLファイルを保存したら、
ShiftJISで保存してるのに、metaではUTF-8してあるような事例でも
お前の場合、文字コードを変更しないっていうんだろ？って皮肉を書いたんだが？ｗ

改行コードもこれと同じで、統一すればいいだけ。
わからないなら説明すればいいし、ちょっとマシン借りて
テキストエディタの文字コードと改行コードのデフォルト設定変えるだけ。

でもお前の場合、そうするのが面倒だから、
ShiftJISで保存されてもむとんちゃくなんだろ？ｗ

>>769
それ古いWindows版gitだろ
だいぶ前から問題ないよ

> 誤ってテキストファイルと分類されたバイナリファイルの場合
そりゃ問題起きるだろ…

自称俺はプログラマじゃなくてプログラマを使う人間まで行ったｗ

>>771
お前ほんと頭悪いな

> ShiftJISで保存されてもむとんちゃくなんだろ？ｗ
最初は当然知らないからどこかで問題が出るよな？
そうなったらどうするか相談とかしてLinuxでチェックアウト時にutf8に変換しようとなる流れだろ
むとんちゃくって意味が分からん…

>>772
だから問題が起きてるだろ？
些細なミスで問題は起きるってことの証明だろ。

gitは直した。じゃあお前が書いたコードは？
バグがない保証は？

ソースコード内の改行コードが勝手に変わっても
正しく動くようにコードを書くわけ？
ちゃんとテストするわけ？

ムダなことしてんなぁｗ

入出力ファイルの話じゃないぞ。内部のデータの話だ。
プログラム内部の改行コードぐらい統一すればいいだろ。

>>774
> そうなったらどうするか相談とかしてLinuxでチェックアウト時にutf8に変換しようとなる流れだろ

ワロタｗｗｗｗ

チャックアウト時にUTF8に変換ｗｗｗｗ
あ、フック書くのかｗｗｗｗｗ

なんか人によって、コミットするたびに文字コードが変わりそうだな。
履歴の差分見たら、ShiftJISとUTF8への変換差分が大量に出そうｗ

ちょっと、アホすぎて面白いから、改行コードじゃなくて
文字コードの話に戻すわｗ

チャックアウト時にUTF8に変換すればいいだってさｗｗｗ


ShiftJISだとUTF8の文字をすべて表せないから、
そういう無知なデザイナや上司が変換するたびにUTF8の文字が壊れそうだな。

でも、そうか、チェックアウト時にUTF8に変換する方法で対応することを
こいつは選ぶわけかｗｗｗｗ

おいE4nKuHZl、お前ヤバイ事になってるぞ…

>>778
ヤバイのはお前の開発の仕方がやばすぎて
笑い過ぎでヤバイだけｗｗｗ

開発の仕方自体は俺のほうがまともだってはっきりしたから
何の問題もないよｗｗｗ

根本的な対応をするんじゃなくて、対処療法的に
起きた問題を直すってやり方をやってるような所は
ソースコードも汚いんだろうな。

俺なら、文字コードや改行コードを間違って保存するような人がいるなら
サーバー側のフックで、ソースコードチェックするのと同じような感覚で
不正な文字コードや改行コードでコミットできないようにするだろうな。

改行コードわかんなかったら確実に文字コードわかんないだろうからな
馬鹿に合わせるならもうこれしかない

新規ファイルは自分で作成しないで絶対にこのテンプレファイルを使用してください
後の美乳ファイルである

結局、改行コードが変わってしまうことで
引き起こされるバグがあるという証拠はいくつも出たけど、

改行コードを変えたほうがいいという理由は
一つも出なかったね。

>>770
プログラマが奴隷だぁ？キャリッジリターンで消してやろうかぁ？

MSVC++がLFだけじゃ改行として認識しないから。
git自体も含めて他の環境のデフォルトはLFだからCRLFに統一するとか有り得ない。
なのでMSVC使うWindows上でだけ自動変換しとけば偶にハマるかもしれんがそれでいいかなと思ってる

>>784
ラインフィードの間違いだったぁ？

fetchってどのくらいの頻度でやってる？

最後にいつfetchしたか忘れたときにやってる

毎日

おまえのオ○ニーと大体同じくらいの頻度だよ

VSがLFだけだと扱えないとかいつの話だよ

ぶっちゃけ、もうソースは全部LFのUTF-8でいいんじゃないかと思う

もちろんUTF-8はBOM無しで

異機種間で統一するならInternetにならってCRLF

>>791
VC++2013の時の話かな
2015では自動変換したものしか使ってないから知らん
まぁ、少なくとも一年前までは問題起きてたわけだ

改行コードの自動変換は良くないって話なんだから
別にWindows専用のソースコードであればCR LF固定でいいんだよ。

Linux系のソースコードなら、Windows版はcygwinかmsysで
コンパイルするわけでこっちはLF固定で良い。

>>795
ウソはいけないよ

ほんとだ。嘘だった。危うく騙されるところだった。

http://www.atmarkit.co.jp/fdotnet/dotnettips/609vsfileencode/vsfileencode.html

> 逆にVisual Studio 2005（以降、VS 2005）のソース・ファイルは基本的に「UTF-8」でエンコードされている。
> そのため、VS.NETからVS 2005へ開発環境を移行する場合などで、（VS 2005のエンコード形式に統一したいなどの理由により）
> そのエンコード（文字コード）を変更したいということはある。このようなファイルのエンコードを変更する機能が
> Visual Studioには搭載されている。それが［保存オプションの詳細設定］だ。
> ［行の終わり］には、改行文字の種類を「Windows（CR LF）」「Macintosh（CR）」「Unix（LF）」などから選べる。

少なくともVS2005、10年前には存在している。

直接的な情報じゃないけど、VS2002 /2003でも改行コードをLFにするそういう設定あるみたいだね。
https://www.techhouse.org/~dmorris/cs148_summer_2005/handouts/OpenGL-Install-Guide.pdf

VC++6.0はどうか知らないけど、ワードパットもLFに対応しているわけで
問題があるのはメモ帳ぐらいじゃないの？

新規に作成するファイルの改行をLFに固定する設定がないから、LFに統一する
運用をしようと思ってもいまひとつ面倒なんだよな。

新規ファイルの改行コードを設定できないエディタなんて
メモ帳ぐらいだろ。

改行コード統一しろ。

>>800
新規ファイルのテンプレートを作って毎回それを使えばいい

WindowsじゃC言語でファイルをテキストモードでオープンした場合だけ
"\n" の出力を "\r\n" つまり CR-LFへ変換するなんてややこしいことになってるんだよね

Unix系じゃファイルのオープンにそもそもテキストモードなんてないし
"\n" はそのまま "\n" つまり LF が出力される

Windowsも改行を LF にして楽になろうよ

>>699はまだコンパイルで死んでるのか？
というか>699生きてる？

>>805
分からないこと多すぎたみたいだからいろいろレス見て勉強させてもらってる
とりあえず今は開発環境を統一させてどうにかさせてる

ずっと居たんかい
コンパイルエラー貼れよ
100レスも無駄に消費しやがって

2時間くらいあれこれやったのをstashして、ブランチ切り替えながらいろいろやってたら
stashしたのが消えてた・・・

もう金輪際stashは使いません

>>808
ほかと違ってgitは些細なミスでソースが失われるので
なにかソースが書き変わる系の作業をするときは
KANARAZUワークスペース丸ごとバックアップした方がいいぞ

メッセージ読まない輩か。

わろた

何が起こったのかな？
サルベージ可能？

その辺はUNIX系コマンドの思想引き継いでるよな
いわく「プログラマーは万能である」。