Git に Contribute してみた

この記事は「Gitのカレンダー | Advent Calendar 2022 - Qiita」の 15日目の記事です。

Git そのものの修正を出したい、手順ってどうすればいいんだろ？
と検索しても GitHub で OSS に貢献（Contribute）する方法みたいなのがヒットして役に立たず。
結局、公式の英語文とにらめっこして Contribute したので備忘録です。

はじめに

出した PR はこちら
https://github.com/gitgitgadget/git/pull/1406

そしてこの修正が含まれた Git 2.39 がリリースされました。

Highlights from Git 2.39 | The GitHub Blog
[ANNOUNCE] Git v2.39.0 - Junio C Hamano

Changes にアカウント名が載ってましたねぇ。嬉しい。

Contribute 方法

さて、まずはじめに Git はよくある OSS のように GitHub での Pull Request を出したらレビューされて Approve されたらマージされる。というフローではありません。
基本的にメーリングリストにパッチを送る形式のようです。

CONTRIBUTING.md

ただ、メーリングリストは自分もそう感じましたが非常にハードルが高いです。（英語だし）
そこで私は GitGitGadget に PR を出す方法で Contribute してみました。
やり方はドキュメントをたどっていけばわかりますが、日本語情報がなかったので、かなり慎重になりました。

ドキュメントはこちら MyFirstContribution

修正をする

修正するまでは他 OSS の場合とあまり変わらないですが、まず gitgitgadget/git に PR 出すのでこちらから fork しましょう。
修正したらビルドして動作確認、テストをすることになります。
この辺は README 読めばわかると思うので省略。
ちなみに今回の PR は1行修正であることと、テストってどうやる？どうやってる？って感じの内容だったのでやってません。
（実際にはやったけど自分の環境では修正と関係ないところがパスしなかった。PR 出すとテストされるのでそっちに任せました。ごめんなさい）

コミットをする

変更できたら、次は commit します。
ここは少し注意が必要です。コミットメッセージは当然英語ですが、そこは頑張ってください。

1つ目は git commit に --signoff (-s) をつける必要がある点です。このオプションを付けるとメッセージに「Signed-off-by: <user.email>」のメッセージが追加されます。
これが必須なので普段つけてない人は気をつけましょう。

2つ目は commit メッセージのフォーマットが決まっている点です。
.editorconfig で1行あたりの文字数が設定されているので、.editorconfig 対応してるエディタでコミットメッセージを編集するのをおすすめします。
コミットメッセージの1行目は変更対象のコンポーネント名を含む 50 文字以下で概要を書きます。
1行空行を空けたあとに、変更の詳細を書きます。
詳細には、コード差分からは読み取れない部分を書くことが重要です。

自分の場合、今回はとにかくメッセージの部分に時間を取られましたが、過去の commit のメッセージを参考にしてシンプルな日本語文章を書いてから、少しずつ翻訳ツールを使って英語のメッセージにしました。
（普段英語できないのにテキトーな英語使ってたが、今回はかなり気を使った。。）

プルリクエストを出す

commit したらプルリクエスト（PR）を出します。
PR を出す先は gitgitgadget/git なので気をつけてください。
やり方はこちらに記載されています。
https://git-scm.com/docs/MyFirstContribution#send-pr-ggg

PR の内容はメーリングリストに流れるカバーレターのタイトルと本文になるので、こちらもドキュメントを参考に書きましょう。

カバーレターについてはこちらに記載されているので、これを参考に PR のタイトルと本文を記載します。
https://git-scm.com/docs/MyFirstContribution#cover-letter

今回のように修正が 1 commit であれば、commit の概要をタイトルにしても良いと思います。
説明文のほうは、commit や commit メッセージでは読み取れない補足情報を書きます。
今回は簡単な内容説明と再現条件を記載しました。

これも過去の PR を参考にすると良いかもしれません。

PR 後の対応

PR を作成すると bot からのメッセージが投稿されます。
こちらにも Contribute 方法について書かれてます。
それに記載されてますが、初めて Contribute する場合は許可された GitHub ユーザー名にないため、すでに許可されたユーザーから /allow のコメントをもらう必要があります。

自分の場合は幸運なことに特になにもせずとも /allow されました。
もし /allow されない場合は issues から /allow コメントを出してる人を探すといいそうです。

（すでに /allow されたユーザーなら誰でも /allow できるっぽいので今度は自分が /allow できるってことか。つまり私に /allow してーと頼むことも可能ってことか。）

次に /submit コメントを書くと、PR の内容がメーリングリストに投稿されます。
が、その前に /preview で投稿されるメールを確認できるので、しておきましょう。
GitHub に登録してるメールにプレビューメールが届きます。
内容に問題がなければ /submit コメントを送ります。

メーリングリストの返信や patch のステータスなどがボットにより自動で PR に送られてきます。
メーリングリストで修正依頼や質問などが来たら返信する必要がありますが、今回は特に眺めてるだけで取り込まれました。（軽微な修正でしたので）
ドキュメントにそのようなケースの対応方法も書いてあったので、たぶんそれを見ながら対応すれば大丈夫だと思います。（経験しなかったので省略）

あとは勝手に進んだのであまり知見として得るものはなかったのですが、待っていたら master に取り込まれて PR は close になります。
（PR は merge されず close になります。取り込まれたかどうかは label でわかりそうです）

最後に

最後の方は待ってるだけで、これなにもしなくていいのかな？認識間違ってるかな？と不安にもなったのですが、結果的に取り込まれてそれがリリースされたのでとっても嬉しいです。
なんか、Git そのものに Contribute するというのはちょっと特別感がある気がします。

Git 自体の修正って大変そう。難しそうというイメージがありましたが、今回の PR 内容は調べてみたらそんなに難しい修正じゃなかったです。みなさんも普段 Git を使っていてなんか変だな？バグかな？と思ったら Contribute にチャレンジしてみてはいかがでしょうか？

とりあえずあまり有益な記事じゃないかもしれませんが、怖くないよってことが伝われば幸いです。ではでは。

【Make formerly Integromat】Twitter でいいねした画像を自動でクラウドストレージに保存する

最近、お絵かきをしたいなと思ってちょこちょこ描いてるのですが、今は昔よりも簡単に上達するための手法や、Twitter の投稿でお手本を見られるので、思っていたよりうまくなった気がしてます（自己満）
まぁまだまだ下手くそなんですけどね。それでも昔のなんかうまく描けないって感じの絵からは脱却できたと思う。

はい。ここまでがまっとうな言い訳なんですが、Twitter でこのひとの絵上手だな、この構図いいな、こんな塗り方もあるのね、といいねした画像がいっぱいあるのですが、参考にしたいなというときにいいねを遡るのは大変なので保存することにしました。
（決して助平心の極みではありません）

では早速シナリオへ

シナリオは 4 つのモジュールだけなので簡単な方です。
まずはじめにトリガーになる Twitter モジュールです。
※Twitter モジュールを使用するので有料プランが必要です。

トリガーは毎時設定で、「List Likes」モジュールで最大5件取得するようにしています。

When to start を過去からにしたら昔のいいねを順次5件ずつ処理されます。
（全件は取得できないです。ページング対応してないからと思われます）

次の Iterator ですが、これは１ツイートに複数の画像がついている場合があるので「Extended entities: Media[]」配列をループさせてます。

次の HTTP モジュールで取得した画像 URL からファイルをダウンロード

最後にダウンロードしたファイルを Dropbox モジュールでアップロードしてます。

アップロード先は好みで変えてください。

（サービスのモジュールがない場合は HTTP モジュールで頑張るか、FTP や SFTP モジュールになると思います）
ファイル名は複数枚画像があった場合に同じファイル名にならないように Iterator からインデックスを取って名前に含めるようにしています。
今回は単純にツイートIDをファイル名に含めるだけにしていますが、Twitter モジュールからツイートの情報が取れるので必要に応じて情報を残すと良いと思います。

実際に運用している Dropbox はこんな感じです。

いいねしておいたら勝手に保存されるので、どんどんいいねしちゃいますね！

ではでは。

git で新規ブランチ作成時の typo を防ぐ

 あまり実用的ではないものの参考までに紹介します。
（というのも最近趣味プログラミングしてなくてネタがない・・）

git でブランチ作成するときに feature って名前をつけることがよくあると思いますが、
これを typo して faeture だったり featrue だったりで push してしまうことがあります。

ただの名前だしまあそんなに気にしなくても。。と思いますが、
ブランチ切替時の入力補完が f や feat とかで止まってしまって1手順増えてしまいます。

たかが1手順とはいえ、体験すると割とストレスだし、開発メンバー全員に影響があることなので実は思っている以上に生産性を下げてしまっている。かもしれません。
（体感です。計測してるわけじゃないです。）

トイルといえるかもしれませんね。
スケールもすると思うので、改善のコスパは良い気がします。

。。少し脱線しましたが、本題へ

commit メッセージの typo チェックはよくあるけど、ブランチ名の typo チェックはあまり聞きません。
ブランチ作成時の hook はなさそうだったので、多くの人が作ってるであろうブランチ作成の alias に手を加える方法にしました。

typo 修正付きブランチ作成 alias

できた alias はこちらです。

[alias]
  cob = "!f(){ echo $1 | sed 's|/| |g' | typos - -w | sed 's| |/|g' | xargs -I% git switch -c %;};f"
  

こうなります。

typo チェックツール

今回使った typo チェックツールは typos です。
他に misspell も使ってみたのですが、feature の typo のいずれのパターンも修正できなかったので typos にしました。

typos は feature_test は分解してチェックしてくれますが、feature/test は分解されなかったので、sed で一度スラッシュを空白に変換してます。
空白にしたのは typos のあとでもとに戻すときに、都合が良いからです。
（_ だともともと _ だったものも / にしてしまう）

ちなみに typos でも faeture は feature になおしてくれますが、featrue はダメでした。
辞書とかあれば改善するかもしれませんが、今回はネタレベルで書いた alias なのでパスします。

最後に

こういったちょっとした手間でもスケールすれば効果は大きくなります。
最近は自称 SRE として改善を生業としてますが、こういったお遊びも役に立つことがあるでしょう。

以上。