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

pull でコンフリクトって、いらないブランチなら他のブランチに切り替えてからブランチ消してチェックアウトし直してる。
その方が -f より安全だったりしない？

ちまちまのときはcommit --fixup とrebase --autosquashが便利よ

まあrebaseしたいなら普通にbranch切ってcommitしてfetchしてrebaseだなあ

そうすれば簡単にFast-Forwardできるから

わたしはいつもreset --hardして合流してからpullしてる

板橋丼もこの方式だったりする
~~~~~~~~~~
[https://pl.kpherox.dev/objects/4c0bd9fa-ca56-48e1-bde0-dd75eaa5b5b1]

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していくともうわけわかめになっていって面倒すぎて