Seems like a standard git thing: have a process that works in a specific, but not a “helpful” way and also have a undiscoverable setting to configure said process.
Is that why people keep building UIs and wrappers for git?
Git has so many users that changing defaults is pretty tricky. They have done it in the past but usually over multiple release cycles with a deprecation window.
Ah yes, like how nginx’s defaults still like to pretend it’s early 2000s, everyone uses dialup, and nobody could possibly want their website to serve more than a handful of requests per hour.
Depends. You can also see those as notes and you want to have them go away after rebase automatically so you have invalidation built in (e.g. preparing changes).
My guess is that it was originally an oversight and this option was added later, but turned off by default to avoid a "breaking change". Would be interesting to dig through the changelogs and commit history to see what the story was.
Yes, it is totally possible to guess it this way. From top of my head reference rewriting while rebase is older thought, but I'd be clueless about it apart from that rebasing is for rewriting commit references in the first place. And everything else - including git-note references - needs to be explicitly configured from that default behaviour. Which follows your argument in a broader sense, as per default no other refs are expected to get rewritten and therefore it shouldn't be different for git-notes, even if they were introduced with the configuration option to rewrite them in the first place.
Is that why people keep building UIs and wrappers for git?