GitHubにあったgolangアプリのリポジトリをforkして改造しようとしていた話の続き。
アプリの本体だけならまだよかったのだが、アプリが使っている別リポジトリのライブラリも改造内容に関わっていて、そっちも変更が必要だ。
go.modで置き換えようとしていたのだが、その置き換えだけのためにライブラリをforkして・・・ということをやっていると、もう私の精神力が持たなかった。
というわけで、こうした。
- 置き換えたいリポジトリたちは、go getではなくgit cloneで$GOPATH/srcの方にcloneする
- cloneしたファイルを編集する
- リポジトリごとにgit diff > xxx.patchなどとしてパッチファイルを取得する
- 差分を取得してpatchにしたり、cloneしてpatchをあてるためのスクリプトを作る
- 自分のリポジトリを作って、そのスクリプトやパッチだけを管理する
cloneするときに、forkしたものをオリジナルと同じディレクトリにするなりシンボリックリンクにするなりでもできそうだけど、自分で間違えてしまいそうな気がするのでね。
なんか、なんかよい方法があるんじゃないかと思うのだが、探しきれてないのよねぇ。
こちらの、オリジナルをgo getしてupstreamにforkした方を載せる、というのがgolangでのやり方なのかな。
github でホストされている go アプリを fork して PR する時には、まず go get から始めよう - Qiita
https://qiita.com/t-suwa/items/d384facb79866dc16cad
stackoverflowにも出てた。
Using forked package import in Go - Stack Overflow
https://stackoverflow.com/questions/14323872/using-forked-package-import-in-go
パッチでやるときの心配は、操作を間違えて消してしまうんじゃないだろうか、というものだ。
それに、一人でやっているからいいけど、複数人でやるとパッチファイルのマージなんかが起きたときに目も当てられないことになってしまいそうだ。
ああ、そうだ、その心配があったな。。。
やっぱりupstream方式にした方が無難か。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。