Linuxの開発者であるLinus Torvalds氏がGitHub上でプルリクエストを受け付けない理由 40
少なくともGitHubのみに依存しないのは正しいと思う 部門より
Redditで「This is why Linus doesn't accept PRs from GitHub」（LinusがGitHubからのプルリクエストを受け付けない理由がこれだ）という画像が話題になっている。
ここで言われている「Linus」は、もちろんLinuxの開発者であるLinus Torvalds氏。この画像は、GitHub上のLinuxのリポジトリに対する「Delete duplicate word "long long" in Introduction」（イントロダクション中でダブっている「long long」という単語を削除）いうプルリクエスト。これに対し、ほかの開発者からが「long long」は単語がダブってるわけではなくそういう型であるとの返答が付いている。
Redditではこれに対し批判と擁護の両方のコメントが寄せられている。Linuxでは過去に単にドキュメントの見出しテキストを装飾するための「-」（ハイフン）が不足しているのを修正するというコミットが受け付けられている例があり、正当な手順で正当な内容の修正が送られれば誰からの修正も受け付けるというスタンスである。
なお、Linus氏はGitHubのプルリクエストを使用しないことを明言しているが、その理由は有効なメールアドレスなどの情報がプルリクエストには抜けていたり、diffが非実用的であるといった理由を述べている。また、Gitのプルリクエスト機能やGitHubのホスティングサービスについては好意的に評価しているが、GitHubのプルリクエストについては総合的に見て劣っており、使えない物となっていると評している。Linus氏はそのことをGitHubに伝えたがGitHub側は取り合わなかったそうだ。
悪いリクエストの典型例 (スコア:5, 興味深い)
プルリクエストは受け付ける側の負担を考慮して出すべきだと思います
たとえばコミットメッセージには
(1)変更の概要(何を変更したか)
(2)変更の理由(何故変更したのか）
の両方を書くべきです
受け付ける側の立場からすると
この２つの情報が揃って初めて merge してみるかという気になります
タレコミのプルリクエストの例では(2)が欠けており
変更の必要性が伝わってきません
これでは無視されたり却下されても文句は言えないと思います
Re: (スコア:0)
> 変更の必要性が伝わってきません
そういう問題だろうか。
あなたは「『ほどほどに』という単語は『ほど』がduplicateして間違っているので修正しました」、というpull requestを「mergeしてみるか」という気になるのでしょうか。
Re: (スコア:0)
ネタなのかマジなのか、わかんねぇなぁ
Re: (スコア:0)
＞「『ほどほどに』という単語は『ほど』がduplicateして間違っているので修正しました」
それをなぜ間違いとしているかが書かれてないから(2)の要件を満たしてないと言ってるように見えるけど
ちゃんと読めてます？
Re: (スコア:0)
普通に考えれば間違いではないのが明らかなので要件以前に日本語（入門書レベルのソース）くらい読めるようになってから来いよオラァん！
という話では？
Re: (スコア:0)
Linux Torvalds氏がスラドを読まない理由
Re: (スコア:0)
理由が他者に分からないならそれは書くべきだし、相手が分からなくて知りたそうな事は書いた方が良いのは一般にコメントと呼ばれるもので共通する配慮ではあると思う。
そのコメントはソースに書かれるべきか、コミットメッセージに書かれるべきか、プルリクエストのコメントに書かれるべきか。
そのコメントは誰が見るもので、その彼は一体何を知らず、何を知りたいのか、難しいよね。
Re: (スコア:0)
C的には一箇所に書いておき たどればいい、でしょうが、
経験的に全部に書くべきと考えます。
まぁソースに書けばあとはコピペですが。
あと誰が見るものか、は考えても無駄です。自分（未来の）に伝わるようにだけ
悩みましょう。
自分すらわからないものが人に伝わるはずありません。
Re: (スコア:0)
いや、あの……。
くだんのプルリクエスト [github.com]は、「C言語にはlong longという型がある」ということを知らない
トンチキ初学者によるもので、変更の必要性が*ない*ことが概要だけから伝わってくる、必要にして十分なものですよ？というか、これ、無理矢理理由を書くとしたら、
(1)変更の概要 : "long long" を "long" に修正した
(2)変更の理由 : "long" が重複していたから
以上に書くことないでしょ。
# long longの存在を知らないレベルの人が、どうしてドキュメントを修正しようと思ったのか、そこが最大の謎。
Re: (スコア:0)
＞(2)変更の理由 : "long" が重複していたから
重複しているのは「事実」であり、その正否を判断する「理由」では無い。
Re:悪いリクエストの典型例 (スコア:1)
理由が書いてあれば、別の修正方法も考えることできますからね
Re: (スコア:0)
重複しているという「事実」なんて無いでしょ。
連続と重複は全然ちがう。
int **PPValue; を見て「*が重複してるのは事実」と言ってるようなもの。
Re: (スコア:0)
＞「*が重複してるのは事実」
これも事実でしょ。
その状態にどのような意味があるかとは何ら関係無い。
これを無意味な重複と判断したのか意味のある連続だが誤った動作と
判断したのかを理由に書くべきだという話。
(1)変更の概要 :フラグAが変更されないように修正しました。
(2)変更の理由 :フラグAが変更されていたため。
これが説明になってると思えるの？
Re:悪いリクエストの典型例 (スコア:1)
> 判断したのかを理由に書くべきだという話。
完全に同意する。
そして同時に、今回のRedittの投稿が、プルリク（のキャプチャ）だけ見せて「これが理由だ」と言っているところが、
まさに「こういう投稿があった」という「事実」を書いただけで「理由」を説明していない、同レベルの投稿になっていて、なんともモニョる。
例えばもう一言、「このレベルの初学者を相手にするのは嫌気がさすだろう」とでも書けば理由の説明になるんだけど。
Re: (スコア:0)
long という文字列が「連続している」は判断を伴わない事実だけど、
「重複している」というのは判断です。
実際「long long」という記載が正しければ、それは重複ではないのが事実です。
Re: (スコア:0)
変更したいと思った理由が「重複しているから」と認識したいうことであって、それには正否もクソもないよ。 その「重複しているという認識」には正否はある。
Re: (スコア:0)
元コメはタイトルの典型例という文言からして、一般論の話として(2)が無いとマージする気が起こらんという話をしているのではなくて？
それを(2)なんか決まっとるじゃないか、とか噛み付くのは愚かな反応かと。
million million (スコア:5, 参考になる)
アイザック・アシモフが、科学エッセイで宇宙のスケールを語る際に、0が12個の意味で「million million」を使ったら、編集者に「million」と書き換えられてしまった、って話がエッセイで語られてました。小学生から(概算した上で)「この表現は桁がおかしいいんじゃないですか」という指摘の手紙が届いたとか。
英語では口語的表現として強調の意味で同じ単語を2回繰り返してしまう場合がよくあり、文語で同じ単語の連続があったら校正でマメに1個に直してくものなんだとか。
long long もそういうありがちなミスだと思い込んで、誤植を見つけたぞとばかりに pull request を投げたんでしょうねぇ。
Re: (スコア:0)
それにしても、long longの意味するところが分からないレベルの人がLinuxカーネルのリポジトリを直そうとしてることに驚き。
# creat()システムコールなんかも、"create"のtypoだってpull requestが上がってきたりするのかなあ。
Re:million million (スコア:2)
変更対象は、ソースファイルではなく、ドキュメントファイルなんですよね。
Linuxカーネルは違いそうだけど、「コードが書けなくても、ドキュメントに貢献することはできますよ」的な事が書いてあるオープンソースプロジェクトは割とよくあるので、
long long の人も、そのノリでプルリクエストを送ってきたのではないかと。
つまり、初学者どころか、C なんて知らんて人の可能性も考えられます。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
そういうタコを大切にするのがLinuxだったと思ってたんだが...
積極性を褒めこそすれ、あげつらうのは良くないよ。BSDじゃないんだから（不適切発言）
Re: (スコア:0)
ああ、タコとか言ってましたねえ懐かしい。しかしそれって日本のユーザーコミュニティの話だったと思うんですが。
どうもLinuxカーネルのコミュニティというと、おかしなことをやらかすと即座にLinusから暴言を投げつけられてシメられる、というイメージが(←偏見)。
Re: (スコア:0)
> 即座にLinusから暴言を投げつけられてシメられる
確かに。そうなると高齢化一直線なんだよなぁ。
Re: (スコア:0)
もしかして: create [google.co.jp]
# ググレカスおまえもか
Re: (スコア:0)
referer
もひとつついでに有名どころ
さすがにgoogleで「もしかして:」とか言われないが
Re: (スコア:0)
billion以上は英米で互換性がないという問題があるのよね。
そんなあなたにSI記数法
重要な情報が欠けているぞ (スコア:1)
「-」（ハイフン）が不足しているのを修正するPRを送ったのは4歳のょぅι゛ょだという。
Re: (スコア:0)
プルリクエストにあわせて、受け取ってコミットする側も幼女・少女というケースも増えていくはず。
魔法少女がブラック職な昨今、これからはコミッター少女が流行るに違いありません。
数年後、「パッチコミッターさくら」(略称: PCさくら)がアニメ化、全国放送される可能性もないとはいえないでしょう。
パッチを回収・コミット、そしてリリースするのです。
ちなみに、使い魔は自動テストやリリースをしてくれるbot。
ではLinusはどのようなやり方をしているか (スコア:1)
GitHubでの”Merge pull request”の弊害 [postd.cc]
この記事が参考になるかも。
GitはLinusが作ったんだからそりゃ自分が使う機能を含めてるに決まってるよな。
「-」（ハイフン）が不足しているのを修正するというコミット (スコア:0)
sをつけただけのコミットでは？
Re: (スコア:0)
下の行にsをつけた結果足りなくなった「-」を補ったんだよ。
長さの誤解が無い整数型 (スコア:0)
これを機会に int64 int64_t あたりが普及してくれる事を願います
Re: (スコア:0)
linux kernelからするとstdint.hを使わないといけなくなるデメリットしかないな
Re: (スコア:0)
Linuxカーネルのように様々な環境に移植されているもので移植性がメリットではないと?
Re: (スコア:0)
デメリットが1つしかないと言ってるだけで(だからやれるね、やろう)、
メリットが無いなんて言ってないと思うんですが。
自分で書いててあれだけど否定ばっかの文で、読みにくいな。
Re: (スコア:0)
kernelは独自定義してるので、stdint.hを使う必要はないし
確実に定義される保証のないものを使うとかあり得ない
それより (スコア:0)
＞diffが非実用的であるといった理由を述べている
これってどういうことだろ？
diffつかわんの？何で差分確認してるんだ？
Re: (スコア:0)
> ＞diffが非実用的であるといった理由を述べている
>
> これってどういうことだろ？
> diffつかわんの？何で差分確認してるんだ？
GitHubのdiffインタフェースが信頼できないということでしょう。
Re: (スコア:0)
ああ、ごめん、そういうことか
Re: (スコア:0)
原文はdiffではなくdiffstatと書いてある
linusはdiffstatが気に入らないのでgitにdirstatを作った
以下推測だが
githubではdirstatを使えなくてlinusはそれが気に入らないのではないだろうか