What I said in my one-sentence-reply is that there are no non-deprecated, built-in tools that helps with this task in a streamlined manner. Which means by extension that it is not a trivial task.
The rule was to not use any external tools so it doesn't qualify.
But you're right. filter-repo is a great tool. You can even use pleasant Python "callbacks" instead of a hodge-podge of env variables and shell snippets.
Some of it might be inherent though. The data structure consists of immutable commits which are addressed by the SHA1 which depends not only on the snapshot but also the metadata as well as the SHA1 of the parents. You run into this immediately when someone thinks that they can maybe just tweak the commit message a little and end up with the same commit. Or drop the second parent of a merge commit in order to “forget” that line of history (effectively making a “squash merge”).
Imagine if someone was working on a SQL database and they thought that an `update` would not change anything in-place but instead would create a new immutable row and that they could reset back to the previous row (before the update) right after that since the immutable row (they thought) would still exist until some arbitrary garbage collection time. You would end up having to explain the same thing but kind of reversed.
It's not the same thing but Git Flow reminds me of Conway's Law. Just that the branches end up representing the dev-test-release workflow.
Another variation is that you reify branches according to whatever team that is working on it, like dev and qa and release. As in they have these literal branches and they need to follow a workflow diagram in order to remember what to merge into what and in what order. Then they mess something up and they go to StackOverflow to ask such easily inteligble questions like:
> We are using a standard branching model. But sometimes we find a bug in release/5613248 and need to deploy a hotfix. So naturally we branch hotfix/5613248 from release/5613248, fix the bug, do a PR against release/5613248/joe-the-gatekeeper, then Joe merges that into release/5613248 and also into pre-release/5613248, qa, and finally into develop. But sometimes we get weird merge conflicts when merging into for example qa or develop. How do we avoid that?
> In djot, we just get rid of indented code blocks. Most people prefer fenced code blocks anyway, and we don't need two different ways of writing code blocks (goal 11).
Sensible. Mostly since it makes other things easier (goal 5), second because one thing is only represented in one way, and thirdly (least important) since indented code blocks are kind of a pain to format compared to fenced code blocks.