Git: 大規模更新と大規模ハックの交錯
今回は単純にGitの話で、初めての人もいるので改めて説明いたしますと、
私が2年ほど前にいぢり始めたのがBatocera32から。
これがあまりに魔改造が過ぎまして、mergeとかもはや無理。
(33~35あたり部分的に適用はしてたですが)
で、古いパッケージが消滅しててビルド不能とかいった事情もありまして
この度は現行のBatocera38まで無茶mergeを敢行せざるを得ない事態。
(試しにブランチを比較してみたあなた、膨大な外部パッケージもあるわけで
こんなもんじゃ済まないっすよ)
さて、どうしてくれようか
大きな問題に直面したとき、いっぺんに対応せず
細分化ししてひとつひとつ…ってカーネギーも云うてはる。
というわけで、まずハック部分をテーマ別に細分化してみましょうか。
なお、ここでは特に激しいハックを施しているRetroArchを例に。
まだ分け足りないかもしれないが、ひとまずこれで。
因みに、ローカルブランチないところは既に適用済。
ひとつっつ地道に
重要且つ汎用性の高いところから。
まずcheckout
移行先へrebase
他全てSkipにするのがポイント
移行先での追加作業用branch
追加の書き換えもあり得るので
確認できたところでpush
当たりどころの悪いmerge解決
conflict解決がこれでいいのか迷ったら、できればpush前に。
一旦移行元に戻す
rebase再挑戦
追加作業
で変更前から未commit状態になる
怪しいところは再検証
後で再検討するため別branchで除けとく
merge先が移動してたりするやつ
公式の移動先を探して自前で要対応
常に公式順が正しいものとして
mergeで変質した部分は戻す必要あり
そしてついに。
現行バージョンに主要ハックが載った
改めて念入りな動作確認要るし、
それぞれのコアも別途対応要るところだけど
山場は突破できたということで。
(対応ブランチ)