Git: 大規模更新と大規模ハックの交錯

今回は単純にGitの話で、初めての人もいるので改めて説明いたしますと、
私が2年ほど前にいぢり始めたのがBatocera32から。
これがあまりに魔改造が過ぎまして、mergeとかもはや無理。
(33~35あたり部分的に適用はしてたですが)

で、古いパッケージが消滅しててビルド不能とかいった事情もありまして
この度は現行のBatocera38まで無茶mergeを敢行せざるを得ない事態。
(試しにブランチを比較してみたあなた、膨大な外部パッケージもあるわけで
こんなもんじゃ済まないっすよ)

さて、どうしてくれようか

大きな問題に直面したとき、いっぺんに対応せず
細分化ししてひとつひとつ…ってカーネギーも云うてはる。
というわけで、まずハック部分をテーマ別に細分化してみましょうか。
なお、ここでは特に激しいハックを施しているRetroArchを例に。

ここに見えてないのも含め、ざっと12系統

まだ分け足りないかもしれないが、ひとまずこれで。
因みに、ローカルブランチないところは既に適用済。

ひとつっつ地道に

重要且つ汎用性の高いところから。

まずcheckout

移行先へrebase

なお、TortoiseGitで作業を進めていきます

当該要素での変更点だけPickで
他全てSkipにするのがポイント

Conflict解決も地道に

移行先での追加作業用branch

移行先に適応させるにあたって
追加の書き換えもあり得るので

確認できたところでpush

当たりどころの悪いmerge解決

conflict解決がこれでいいのか迷ったら、できればpush前に。

一旦移行元に戻す

おもむろにreset

hardで元リポジトリの状態まで戻す

rebase再挑戦

conflictうじゃうじゃ

どっちか迷ったら、とにかく両方残す選択

追加作業

追加作業用ブランチを移行先の変更前までsoft reset
で変更前から未commit状態になる

確実なところから順にcommitしなおし
怪しいところは再検証

関係なさそな変更点が紛れてたら
後で再検討するため別branchで除けとく

merge先が移動してたりするやつ

移動元に対するハックはなかったことになるので
公式の移動先を探して自前で要対応

テーブルの順番が変わってたりするのもしんどい
常に公式順が正しいものとして
mergeで変質した部分は戻す必要あり

そしてついに。

難攻不落のRetroArch
現行バージョンに主要ハックが載った

改めて念入りな動作確認要るし、
それぞれのコアも別途対応要るところだけど
山場は突破できたということで。

(対応ブランチ)