のえる DTP鯖管 @noellabo@dtp-mstdn.jp

https://dtp-mstdn.jp/users/noellabo/statuses/102048101167023152
こういう、ローカルな変更が本家の更新とぶつかり合うかもしれない、など考えると、自分には改造はかなり難しい。
改造も何もしていないPleromaでも単なるgit pullで、小さい問題がしばしば起きる。

本質的にはもっとプラグイン可能な構造にして、本体(プラットホーム？)の改造はできるだけ避けられるように設計しなおせれば一番よいけど、それを望むのは無理でしょう。
せめて、プラグイン可能な本体の設計法について学びたいけど、どういうキーワードがあるのかすらわからない。
そういうソフトウェア技法はあるはずだと思うけど。少し前に調べた時は、plugin frameworkという言葉が見つかった。

ブーストウォッチめっちゃおもしろい。

git ホント何もわかっていないので、とても怖い

ローカルリポジトリに、本家リモートリポジトリへの参照ブランチを作っておくという手法は、次のページで学びました。
https://qiita.com/xtetsuji/items/555a1ef19ed21ee42873

こうしておくと、本家への追従がしやすいです

反応を集めたいなら discourse とかでやった方が良さそう (仕組み的には)

submoduleは別のトラブルを生みがちな印象があって敬遠しがち

タグのマージはなぁブランチ違えばcherry-pickのrebase混じりになるからしんどいだろうなぁ…うーん

ブーストウォッチ、本当は投稿そのものを取りたかったんだけど、作った当時はAPIアクセスしか使っていなくてActivityPubなんもわからん状態だったので、他サーバの投稿をとる方法が無くてこんな感じになってしまった。

boostwatch、リンクじゃなくて実際のBT先トゥートまで表示されてれば完璧なんだけども

いうのが私の運用だけどremoteが複数あると管理めんどくさいところあるかもなぁみたいな

upstreamをわざわざmasterに取っておく意味はあんまりないと思うからremoteにupstream追加してgit fetch --allすればいいかなぁって

動かす用ブランチを生やして、そっからrebaseしていく方針
mergeしていくともうわけわかめになっていって面倒すぎて

git rebase は PR する時とか feature- ブランチとかで 1 コミットにまとめておきたい時くらいしかまだ使っていない（他の使い方を知らない

ブランチ名について：
upstream_master：本家をリモートリポジトリとして追加したもの
master：自分のリポジトリのmaster
crazynewworld：弊鯖の独自変更のブランチ

コマンド：
git checkout upstream_master
git pull
git pull --tags
git checkout master
git merge upstream_master
git push origin master
git push origin --tags
git checkout crazynewworld
git rebase master

ここでコンフリクトがあったら該当ファイルを修正して、
git add <修正したファイル名>
git rebase --continue

rebaseが通ったら、例によってbundle updateとかやーんとかmigrateとかprecompileとかリスタートとかやって、最後に

git push -f origin crazynewworld

github 上で指差し PR はやりますね……あれなんで最初は必ず本家向いちゃうの……

指差し git 割とやる
history 打って手順ちゃんとやったかの確認も

gitのrebase、よく理解してなくて歴史を改竄するときにしか使っていない。

pull -f的なやつ、コンフリクトでresetもなんかエラー出るみたいな時があって、別のブランチを作ってそっちに切り替えたあと、masterブランチを消して、originからmasterを取り直す。ということをしたことがある。