Git 16©2ch.net

2017/08/15(火) 00:54:07.61

ソースコード管理を行う分散型バージョン管理システム、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

2018/06/09(土) 15:18:34.95

どうです？原発問題とMSのgithub買収にはなんの関係もありませんが、
こうやって原発問題を批判すると、なんてことでしょう？MSがひどい会社に
見えてきませんか？これが話術というものです。

2018/06/09(土) 15:29:14.63

なるほど

2018/06/09(土) 15:51:30.49

>>228
書いたやつもコメントもアホすぎわろた

2018/06/09(土) 19:44:06.05

単なるアレルギーでgitlabに移行する奴は、ロクに技術選定出来ないだろうし、一緒に仕事したくない

2018/06/09(土) 19:46:57.88

gitlabはオープンソースにする理由がなく
逆にソースを外部に預けることができない
政治的な理由がある場合に
社内サーバーにインストールして使うものだろう

2018/06/09(土) 20:07:09.85

ローカルなリポジトリならなんでもいいからgitlab固有のメリットではないかな
gitlabは多機能だから他のサービスを乱立しなくても開発環境を作れるのが便利(jenkinsやめてgitlab-ciなど)
あとはブランチのアクセスコントロールは便利だと思う
本当はSVNみたいにサブディレクトリ単位でアクセスコントロールしたいけど…

2018/06/11(月) 10:48:33.34

社内とか部署内専用でやるならgit単独で充分

2018/06/11(月) 11:05:30.72

いやいやそんなわけない

2018/06/11(月) 11:13:11.41

オンプレミスでやるにしてもGitBucketのローカルインストール版とか使った方がgit単独より便利だぜ

2018/06/11(月) 21:47:40.12

Googleにお薦めされたgitの記事なんだけどなんだこれ
https://qiita.com/carotene4035/items/469569a5b5b9904f7d32

2018/06/12(火) 00:45:20.77

>>242
今流行りの異世界転生物ラノベやな

に作者の
「あー、人生やり直してー、今の記憶を持ったまま、レベルMAXでやり直してー」
という願望からスタートする妄想やで

2018/06/12(火) 16:48:02.14

単にどこまで戻るかっていうより
失敗したとこまで戻ってやり直しても
それ以降の上手く行ってる部分はそのまま継続したいっていう
みんなが持ってる願望

2018/06/17(日) 14:20:59.87

Git で使っている、SHA-1だけど去年位からそろそろやばいっていう感じになってきて、
object_id っていう感じで切り出しを進めていたんだけど、次の2.18 でほぼ外出しできる模様。

次の次ぐらいで、SHA-1を置き換える動きが加速するかもね。

2018/06/19(火) 13:28:44.57

ハッシュアルゴリズムの脆弱性が出たとき既存レポジトリは
どうにかできるんだろうか？
githubの人に会ったときに聞いとけば良かった

2018/06/19(火) 17:45:29.23

オブジェクトのIDが復号されたらなにがまずいのw

2018/06/19(火) 22:39:40.18

指定したハッシュ値を持つオブジェクトって、もう簡単に作れるのかな？

2018/06/19(火) 23:24:32.85

中身が何でも良ければ簡単だろ

2018/06/20(水) 18:29:35.80

2.18が出る直前になって、MLに　 "security: potential out-of-bound read at ewah_io.c |ewah_read_mmap|"
って、セキュリティバグほどではないけど、少しやばいのが見つかって、2.18のリリースが少し遅れている模様。

2018/06/20(水) 18:33:45.25

gitの開発グループではハッシュ値をobject_id に切り出しているんだけど、
それ以外にもMLに "Kill the_index part 1, expose it" っていうメールが
投げられて、index を隠蔽しようという動きも出てきている。

2018/06/22(金) 23:34:06.81

Git v2.18.0

2018/06/25(月) 22:16:42.85

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.とかになるのかなー

2018/06/25(月) 22:22:27.55

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

2018/06/26(火) 02:29:12.11

へーすごい
https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/

2018/06/26(火) 05:31:08.36

githubを手に入れたMSがgitにまで手を入れてくるってことだな。
まずgithubを対応させる。そしてgitの拡張プラグインを作る
git本家に対応を迫る

2018/06/26(火) 07:37:27.91

>>256
何言ってんのｗｗｗ

2018/06/26(火) 08:56:13.84

>>257
サーバーサイドで処理するgitコマンドが増えるって話だよ

2018/06/26(火) 10:29:54.56

>>258
ちゃんと読んだ？

2018/06/26(火) 11:30:32.83

なにを？俺はこれからのgitが
どうなるかって話をしただけだが？
今起こってる何かの話じゃなくて

2018/06/26(火) 18:41:01.36

powershell化するん

2018/06/26(火) 20:23:46.80

>>256
統失

2018/06/26(火) 20:30:32.42

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/

2018/06/26(火) 21:30:29.52

gitがWindowsのAPIに対応しないでmsys依存で動いてた期間が長かったからねえ

2018/06/26(火) 21:32:26.03

あとVSのgit対応はAndroidStudioに比べて酷く見劣りする

2018/06/26(火) 21:33:24.80

>>265
たとえば？

2018/06/27(水) 00:23:55.22

>>266
今時のIDEなら、ソースの編集画面で、行が修正されてたかどうか表示があるよね？

AndroidStudio はこれがカレントブランチのHEADから修正されてるかどうかを表示してくれる
最新バージョンだと、この修正されてるかどうかの表示から、行の固まりを直接コミットできたりする
add -p がソースの編集画面でできるってことね

全体的に、ソースの編集が、ファイルを編集するのじゃなくて、コミットを編集するイメージでできちゃうのがいい

2018/06/27(水) 02:00:45.52

>>267
それが「酷く見劣りする」のかい？

2018/06/27(水) 04:19:45.96

>>267
正直ニッチ需要

2018/06/27(水) 10:20:54.35

VSは、ファイルシステム上のソースを編集するIDEに、レポジトリを操作する機能を追加しただけ
Android Studioはレポジトリ上のソースを直接編集するIDEになりつつある

前者が一周遅れているのを酷く見劣りすると表現した
後者はニッチなんかじゃなくて、これからIDEの基本的機能になるよ

2018/06/27(水) 10:29:05.13

>>270
具体的に

2018/06/27(水) 10:36:13.05

>>271
>>267

2018/06/27(水) 12:35:11.22

>>270
どうでもいい機能

2018/06/27(水) 13:00:46.70

この辺どうでもいいって言ってる奴は、コミットする時statusやdiffで確認とかしてなそう
gitignoreも適当で何でもかんでもコミットに突っ込むタイプ

2018/06/27(水) 13:06:25.02

>>274
根拠のない決めつけ頭おかしい

2018/06/27(水) 13:08:26.72

>>270
いらない機能だね

2018/06/27(水) 13:09:55.91

マウント取りたいだけやろ？

2018/06/27(水) 14:05:29.15

>>275
>>267みたいな機能は、>>274みたいな奴には必要ない機能だからね
逆にコミットを丁寧に作りたい奴にはとても便利な機能

2018/06/27(水) 14:49:54.17

無駄な機能使って悦に浸りたいだけか

2018/06/27(水) 17:09:02.20

底辺には必要ない機能

2018/06/27(水) 20:20:31.88

中央管理に逆戻りしてるだけにしか思えん。

2018/06/27(水) 22:46:24.77

どこが中央管理？

2018/06/28(木) 01:01:00.14

これだからコミットオナニストは困る

2018/06/28(木) 01:24:53.49

糞みたいなコミットでプルリク投げんなよ
買ってもらったGithubが泣いてるぞ

2018/06/28(木) 03:05:25.22

ﾌﾞｰｲﾓへの賛同者なし

2018/06/28(木) 03:11:08.11

MS が周回遅れなのはいつもの事だろ

2018/06/28(木) 03:12:58.41

GUIも
インターネットも
OSSも
Gitも
いつも手のひら返し

2018/06/30(土) 02:36:01.41

Supercharging the Git Commit Graph
https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/

MSの人がGit 2.18 のcommit graph について熱く語っている。

2018/06/30(土) 07:37:56.40

>>288
>>255

2018/06/30(土) 10:51:20.67

>>288
ありがとう

2018/06/30(土) 14:13:16.44

>>288
thx!

2018/06/30(土) 14:36:14.41

>>288
この改善は、普通の規模のリポジトリにはほとんど影響無い

モジュール分けしてなくて馬鹿みたいにでかい原始的なWindowsのリポジトリをそのままGitで管理するようにしたら、log --graph の表示が遅すぎて使い物にならなくなって、しょうがないから git に対策入れたって話

2018/06/30(土) 15:13:57.50

>>292
よく読んでみ
WindowsじゃなくてLinuxを指標としてるから

2018/06/30(土) 16:03:54.28

>>293
指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ

Linuxカーネルリポジトリで異様に改善されてるのは branch --contains だけ
これはそんな頻繁に使うもんでもないし、ブランチ全部ローカルにpullしてくる必要もないんで特に問題にならん
log --graph 6秒も許容範囲

それにくらべて、WindowsリポジトリはGVFS使ってチートしてるのに、log --graph が24秒もかかって、
これは使ってる人切れるだろ
今回の改善でこれがなんとか5秒になるわけだ

2018/06/30(土) 16:28:43.58

>>294
自分に都合のいいコマンドだけ取り出すとは苦しいね
>指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ
Gitについては言及なしかい？

2018/06/30(土) 16:45:16.91

>>295
Git のレポジトリが普通の規模のリポジトリ
コマンド1回あたり数百ミリ秒が数十ミリ秒になったって意味ない
だからほとんど影響無いって >>292で書いてる

俺にとって都合の悪いコマンドのことを書いてくれない？

2018/06/30(土) 17:20:25.83

>>296
どうやら数値が目に入らないようだ

2018/06/30(土) 17:26:41.23

>>296
お前が許容できるかどうかじゃなくて純粋に数値を見なさい
6秒近くかかってたのが1秒もかからなくなることに価値を見いだせないならこの業界向いてないよw

2018/06/30(土) 17:51:45.08

>>297-298
Linuxカーネルで6秒が1秒になったのなんて、Windowsリポジトリで24秒が5秒になったのに比べれば全然たいしたことないな
6秒を問題とするなら、Windowsリポジトリが5秒になったのなんて全然問題解決してないじゃん阿保かと

2018/06/30(土) 18:04:27.07

git使っててコマンドライン操作にこだわるのはいいけど
コミットグラフ意識してないひとマジでちゃんと勉強してほしい

2018/06/30(土) 18:17:49.02

なにをどう意識すりゃいいんだっけ？

2018/06/30(土) 18:21:22.82

>>300
意識したらどうなるの？

2018/06/30(土) 18:21:50.47

>>300
ちゃんとコマンドラインにこだわってる人は、
log --graph --branches --remotes --pretty=format:～
とかを使ってコミットグラフ表示を見てると思うけどね

2018/06/30(土) 18:35:18.00

>>299
阿呆はお前やろｗｗｗ
悔しかったらお前もGitのパフォーマンス改善してみれば？

2018/06/30(土) 18:38:07.46

>>299
これをたいしことないと思えるとはすごいな
仕事でもいまだにXPのRAM2GBとか使ってそう

2018/06/30(土) 19:09:03.95

>>305
巨大なレポジトリで頻繁に log --graph 見るようなときはローカルブランチで作業中とかなので、コミット範囲指定すれば一瞬で結果返ってくるし特に気にならない
いま試しにlinuxカーネルレポジトリクローンしてみたけど、master上だと確かに数秒かかるけど、ローカルブランチからならコミット範囲指定して一瞬だわ

2018/06/30(土) 19:25:00.31

ストップウォッチで6秒を誤差1秒以内で押せる人だけが、
速くなったすげーすげーと喜びなさい

2018/06/30(土) 19:35:18.92

pullするときにガンガンマージコミット作る人とかいるやん？
ちゃんと設定しといてほしい

2018/06/30(土) 19:44:02.17

>>308
何を？

2018/07/01(日) 12:15:12.44

>>309
git config --global --add merge.ff false
git config --global --add pull.ff only

2018/07/01(日) 13:21:15.23

>>310
その設定嫌いだから断る

2018/07/01(日) 16:05:21.27

addやcommitする際に特定の文字列が含まれているフォルダ以下を除外する方法を教えてください
datasets-XX、datasets-YYのようなフォルダを除外したいです

2018/07/01(日) 16:22:29.58

.gitignore じゃなくて？

2018/07/01(日) 19:59:41.54

.gitignoreに*datasets*と書いたんですけどadd *とやると無視してくれませんでした

2018/07/01(日) 23:12:13.45

>>311
この設定が嫌って、、
gitをSVNみたいに使ってるところとか？
こわい

2018/07/01(日) 23:20:32.85

>>315
押し付けがましい変な奴

2018/07/02(月) 00:33:57.45

>>314
すでにコミットされてるファイルが存在するフォルダは.gitignoreに追加しても無視できない
それをあえて無視したい場合には以下のどっちかを使うんだけど
git update-index --assume-unchanged
git update-index --skip-worktree
どっちを使うべきかは git update-index でググってみて

2018/07/02(月) 02:50:26.22

プロはgit pullなんか使わない

2018/07/02(月) 05:54:16.00

>>318
そんなこと言ってるやつがいたら、そいつはプロじゃない

理由が上から目線で馬鹿はミスするから使うなだったら
完全にアウト。自分（ミスした本人）が理解してない証拠

2018/07/02(月) 08:33:58.94

おれも普段はfetchとmerge使って
pullはffが確定してる特定条件でしか使わんなあ

2018/07/02(月) 09:37:34.88

fetchとmergeで済むならpullでいいだろｗ

2018/07/02(月) 09:50:53.90

例えばmvはcpとrm使ってやれるけど、mv使うでしょ？
それと同じだよ。楽な方使え

それにgitのよくある使い方は、pullしたブランチにコミットを追加するのではなく
新たにそこからブランチを切って作業する。
そしてpullしたブランチっていうのは通常他人の作業ブランチ。
だから他人がコミットを追加する。

つまり何が言いたいかというと
1. pullしたブランチは、他人の手によって成長する
2. 自分はそのブランチにコミットを追加しない
ということなんだから、ffは高い確率で確定している
多くの場合はgit pullでOK（--ff-onlyつけときゃffできないときエラーになる）

fetchしてmergeは、cpしてrmするのと同じで、無駄な作業をやってるだけ
そういうのは丁寧な作業でもなんでもないから

2018/07/02(月) 11:11:12.46

merge するときだけ fetch するわけじゃなくて、上流の状態を確認するために fetch は頻繁にやってるのよね
だから merge するときも、まず fetch してブランチの確認してから、問題なければ merge する手順でやる

あと >>322 は、今の一般的な git の使い方とは思えない
他人の作業ブランチをpullするとか自分のとこじゃかなりレアケースで、mergeするのはmasterなりdevelopとかの上流のブランチなことがほとんどだよ

2018/07/02(月) 12:07:23.83

mergeするのは
自分の作った自分だけがコミットするフィーチャーブランチを
他の人とも共有して使うブランチにマージする時、
っていうのが多いよね

フィーチャーブランチを作ったのがだいぶ前でも
コンフリクトがなさそうなときは
masterブランチのヘッドにリセットハードしてからフィーチャーブランチをマージ、
コンフリクトしまくる場合はいったんmasterブランチをフィーチャーブランチにマージしてコンフリクトを解決してからmasterブランチにマージ、
時間あるときはリベース
そんな感じじゃないの

2018/07/02(月) 12:37:42.51

>>324
だいたいそんな感じだけど、masterのヘッドにリセットハードってチェックアウトじゃダメなの？

2018/07/02(月) 12:58:12.03

>>325
実は>>324に書いてる方法はあまりやらず、本当はpullしない派なので、、
異端なのかな、、

fetchしまくって常にmasterブランチの動向を監視、
他の人の作業でmasterブランチが成長してきてmergeできなさそうになってきたら
再度フィーチャーブランチを作って
元のフィーチャーブランチの作業をすべてチェリーピック、
フィーチャーブランチの作業が終わればmasterブランチの先端に合わせて（リセットハードして）フィーチャーブランチをmerge
こんな感じ

2018/07/02(月) 14:12:01.33

>>323
> 他人の作業ブランチをpullするとか自分のとこじゃかなりレアケースで、mergeするのはmasterなりdevelopとかの上流のブランチなことがほとんどだよ
master、developも含めて、他人だよ。

masterやdevelopに自分が直接コミットすることはない。
このブランチからはgit pullするだけ。
そしてそれは常にffになる。ffにならないのは異常事態
誰かがとんでもないミスをしたということ

ffになったかどうかはgit pullのログ見てればわかることだし
--ff-onlyつけてれば、ff以外は弾かれる

つまりは、あんたは
fetchして問題ないか"毎回"確認してmergeしてる
俺はgit pullして"問題があったときだけ"確認してる

2018/07/02(月) 14:26:56.91

俺の場合

> fetchしまくって常にmasterブランチの動向を監視、
git pullしまくって常にリモートのmasterに
ローカルのmasterを追尾

masterが変更されるたびに、
フィーチャーブランチをgit rebase master
マージできる場合は、git rebase masterは成功する
コンフリクトが起きればマージできないということ
「mergeできなさそう」なんて曖昧な判断はいらない
コンフリクトを解決すれば、当然またマージできるようになる

ただしプルリク出したあとは、他の誰かがレビューしたってことなので
その作業が無駄（分かりづらく）にならないようにmasterをマージする方法に切り替える
（masterをマージすることで逆に分かりづらくなる場合はgit rebase masterする場合もある）

2018/07/02(月) 14:30:09.48

>>326に書いてある

> 再度フィーチャーブランチを作って
> 元のフィーチャーブランチの作業をすべてチェリーピック、

git rebase master一発で↑これ相当のことをやってることになる

>>326はmergeできなさそうになったらやると言ってるが、
俺はmasterが変更になるたびにやってる。
git rebase masterならそれが可能。しかも簡単。

2018/07/02(月) 15:06:13.90

>>327
別にpullが失敗するかどうかだけを確認してるわけじゃない

masterからブランチ切るときとか、masterにマージするときには、origin/masterの状況がどうなってるか確認したいからまず fetch する

2018/07/02(月) 15:07:13.34

>>328
fetch はフィーチャーブランチがカレントブランチのままできる

いちいち master を checkout して pull しまくるとかマゾなの？

2018/07/02(月) 15:09:33.33

>>331
じゃあお前どうやってんの？