Git 16©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ソースコード管理を行う分散型バージョン管理システム、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 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured M$とは大違いだな
>さらに、追加のセキュリティレベルとして、これらのリリースでは、問題のある.gitmodulesファイルを含むリポジトリへの
>pushesを拒否する。これは、次のことを意味する。
>ホスティングサイトが悪意のあるコンテンツの拡散を防ぐことで、古いクライアントを使っている顧客を保護します。 >>225
ここで述べられてるいくつかの脆弱性・修正のうち、
https://www.infoq.com/jp/news/2018/06/git-vulnerability-2.17
NTFSに関するものはこれだけでは？
> 修正された脆弱性の2つ目は、NTFSファイルシステムを使用するレポジトリに
> 特有の脆弱性であり、攻撃者がランダムなメモリ内容を読み取れるように
> NTFSパスの健全性チェックを欺くことができる。
つまり、あんたの引用したそれはNTFSとは関係ない
Linuxにも影響がある脆弱性 こういう記事を見てもMSを批判することは、かっこいいことみたいだね。
GitHubからGitLabへ移行しよう
ttps://qiita.com/flmil/items/89ca07fa976546365c49
> きっかけは、Microsoftは2018年6月4日（米国時間）に、
> GitHubを(約75億ドルで)買収すると発表したことだ。 放射脳みたいなものだね
昔ちょっと失敗したからっていつまでも原子力はダメだと言うのはばかばかしい
Microsoftも確かに悪い時期はあったけど今はユーザーや開発者にとってすごくいい会社だよ >>229
原子力は問題ですね、特にビジネスロジックの中にリスク管理が全く含まれないところが
原子力も保険に入る必要があるのですが、その保険を定義できない常況なのです >>229
原発でマスゴミの可笑しなところは
事故前(もんじゅとか美浜とかの時代)は少量漏れただけであれほど危ない危ないって騒いでたのに
事故が大きくなると何も言わなくなったこと
今も騒ぎ続けてないと可笑しいんだが
発狂して死んでもいいレベル どうです？原発問題とMSのgithub買収にはなんの関係もありませんが、
こうやって原発問題を批判すると、なんてことでしょう？MSがひどい会社に
見えてきませんか？これが話術というものです。 単なるアレルギーでgitlabに移行する奴は、ロクに技術選定出来ないだろうし、一緒に仕事したくない gitlabはオープンソースにする理由がなく
逆にソースを外部に預けることができない
政治的な理由がある場合に
社内サーバーにインストールして使うものだろう ローカルなリポジトリならなんでもいいからgitlab固有のメリットではないかな
gitlabは多機能だから他のサービスを乱立しなくても開発環境を作れるのが便利(jenkinsやめてgitlab-ciなど)
あとはブランチのアクセスコントロールは便利だと思う
本当はSVNみたいにサブディレクトリ単位でアクセスコントロールしたいけど… オンプレミスでやるにしてもGitBucketのローカルインストール版とか使った方がgit単独より便利だぜ >>242
今流行りの異世界転生物ラノベやな
に作者の
「あー、人生やり直してー、今の記憶を持ったまま、レベルMAXでやり直してー」
という願望からスタートする妄想やで 単にどこまで戻るかっていうより
失敗したとこまで戻ってやり直しても
それ以降の上手く行ってる部分はそのまま継続したいっていう
みんなが持ってる願望 Git で使っている、SHA-1だけど去年位からそろそろやばいっていう感じになってきて、
object_id っていう感じで切り出しを進めていたんだけど、次の2.18 でほぼ外出しできる模様。
次の次ぐらいで、SHA-1を置き換える動きが加速するかもね。 ハッシュアルゴリズムの脆弱性が出たとき既存レポジトリは
どうにかできるんだろうか？
githubの人に会ったときに聞いとけば良かった 指定したハッシュ値を持つオブジェクトって、もう簡単に作れるのかな？ 2.18が出る直前になって、MLに "security: potential out-of-bound read at ewah_io.c |ewah_read_mmap|"
って、セキュリティバグほどではないけど、少しやばいのが見つかって、2.18のリリースが少し遅れている模様。 gitの開発グループではハッシュ値をobject_id に切り出しているんだけど、
それ以外にもMLに "Kill the_index part 1, expose it" っていうメールが
投げられて、index を隠蔽しようという動きも出てきている。 https://public-inbox.org/git/20180609205628.GB38834@genre.crustytoothpaste.net/T/#t
> To summarize my view, I think my ordered preference of hashes is
> BLAKE2b, SHA-256, and SHA3-256.
だって。SHA3-256.とかになるのかなー Introducing Git protocol version 2
Friday, May 18, 2018
https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html
git 2.18 から protocol v2 の機能が入ってきた模様。
1) Server-side filtering of references
2) Easy extensibility for new features like ref-in-want and fetching and pushing symrefs
3) Simplified client handling of the http transport githubを手に入れたMSがgitにまで手を入れてくるってことだな。
まずgithubを対応させる。そしてgitの拡張プラグインを作る
git本家に対応を迫る >>257
サーバーサイドで処理するgitコマンドが増えるって話だよ なにを？ 俺はこれからのgitが
どうなるかって話をしただけだが？
今起こってる何かの話じゃなくて MSって以前からgit に積極的じゃん
MicrosoftがWindowsのコードリポジトリをGitに移動
https://www.infoq.com/jp/news/2017/07/microsoft-windows-git
Visual Studio のgit 対応とかもやってるし。
それから、↓のJohannes SchindelinもMSの人だよね。
https://git.github.io/rev_news/2018/05/16/edition-39/ gitがWindowsのAPIに対応しないでmsys依存で動いてた期間が長かったからねえ あとVSのgit対応はAndroidStudioに比べて酷く見劣りする >>266
今時のIDEなら、ソースの編集画面で、行が修正されてたかどうか表示があるよね？
AndroidStudio はこれがカレントブランチのHEADから修正されてるかどうかを表示してくれる
最新バージョンだと、この修正されてるかどうかの表示から、行の固まりを直接コミットできたりする
add -p がソースの編集画面でできるってことね
全体的に、ソースの編集が、ファイルを編集するのじゃなくて、コミットを編集するイメージでできちゃうのがいい VSは、ファイルシステム上のソースを編集するIDEに、レポジトリを操作する機能を追加しただけ
Android Studioはレポジトリ上のソースを直接編集するIDEになりつつある
前者が一周遅れているのを酷く見劣りすると表現した
後者はニッチなんかじゃなくて、これからIDEの基本的機能になるよ この辺どうでもいいって言ってる奴は、コミットする時statusやdiffで確認とかしてなそう
gitignoreも適当で何でもかんでもコミットに突っ込むタイプ >>275
>>267みたいな機能は、>>274みたいな奴には必要ない機能だからね
逆にコミットを丁寧に作りたい奴にはとても便利な機能 糞みたいなコミットでプルリク投げんなよ
買ってもらったGithubが泣いてるぞ GUIも
インターネットも
OSSも
Gitも
いつも手のひら返し >>288
この改善は、普通の規模のリポジトリにはほとんど影響無い
モジュール分けしてなくて馬鹿みたいにでかい原始的なWindowsのリポジトリをそのままGitで管理するようにしたら、log --graph の表示が遅すぎて使い物にならなくなって、しょうがないから git に対策入れたって話 >>292
よく読んでみ
WindowsじゃなくてLinuxを指標としてるから >>293
指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ
Linuxカーネルリポジトリで異様に改善されてるのは branch --contains だけ
これはそんな頻繁に使うもんでもないし、ブランチ全部ローカルにpullしてくる必要もないんで特に問題にならん
log --graph 6秒も許容範囲
それにくらべて、WindowsリポジトリはGVFS使ってチートしてるのに、log --graph が24秒もかかって、
これは使ってる人切れるだろ
今回の改善でこれがなんとか5秒になるわけだ >>294
自分に都合のいいコマンドだけ取り出すとは苦しいね
>指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ
Gitについては言及なしかい？ >>295
Git のレポジトリが普通の規模のリポジトリ
コマンド1回あたり数百ミリ秒が数十ミリ秒になったって意味ない
だからほとんど影響無いって >>292で書いてる
俺にとって都合の悪いコマンドのことを書いてくれない？ >>296
お前が許容できるかどうかじゃなくて純粋に数値を見なさい
6秒近くかかってたのが1秒もかからなくなることに価値を見いだせないならこの業界向いてないよw >>297-298
Linuxカーネルで6秒が1秒になったのなんて、Windowsリポジトリで24秒が5秒になったのに比べれば全然たいしたことないな
6秒を問題とするなら、Windowsリポジトリが5秒になったのなんて全然問題解決してないじゃん阿保かと git使っててコマンドライン操作にこだわるのはいいけど
コミットグラフ意識してないひとマジでちゃんと勉強してほしい >>300
ちゃんとコマンドラインにこだわってる人は、
log --graph --branches --remotes --pretty=format:〜
とかを使ってコミットグラフ表示を見てると思うけどね >>299
阿呆はお前やろｗｗｗ
悔しかったらお前もGitのパフォーマンス改善してみれば？ >>299
これをたいしことないと思えるとはすごいな
仕事でもいまだにXPのRAM2GBとか使ってそう >>305
巨大なレポジトリで頻繁に log --graph 見るようなときはローカルブランチで作業中とかなので、コミット範囲指定すれば一瞬で結果返ってくるし特に気にならない
いま試しにlinuxカーネルレポジトリクローンしてみたけど、master上だと確かに数秒かかるけど、ローカルブランチからならコミット範囲指定して一瞬だわ ストップウォッチで6秒を誤差1秒以内で押せる人だけが、
速くなったすげーすげーと喜びなさい pullするときにガンガンマージコミット作る人とかいるやん？
ちゃんと設定しといてほしい >>309
git config --global --add merge.ff false
git config --global --add pull.ff only addやcommitする際に特定の文字列が含まれているフォルダ以下を除外する方法を教えてください
datasets-XX、datasets-YYのようなフォルダを除外したいです .gitignoreに*datasets*と書いたんですけどadd *とやると無視してくれませんでした >>311
この設定が嫌って、、
gitをSVNみたいに使ってるところとか？
こわい >>314
すでにコミットされてるファイルが存在するフォルダは.gitignoreに追加しても無視できない
それをあえて無視したい場合には以下のどっちかを使うんだけど
git update-index --assume-unchanged
git update-index --skip-worktree
どっちを使うべきかは git update-index でググってみて >>318
そんなこと言ってるやつがいたら、そいつはプロじゃない
理由が上から目線で馬鹿はミスするから使うなだったら
完全にアウト。自分（ミスした本人）が理解してない証拠 ■ このスレッドは過去ログ倉庫に格納されています
