If the thinking was truly "slower", i.e. have less throughput, it would result in fewer insights overall, i.e. lower intelligence. This doesn't seem to be the case since the author describes equal success of these "slow thinkers" to neurotypical ways of thinking.
The problem therefore seems to be more accurately described as having the same insights as others, but they arrive later, i.e. "delayed" insights.
Delayed processing could be an effect of delayed context switching, i.e. monotropism [0]. Monotropism can be an indicator of mild autism.
Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.
Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started.
That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.
Git Town contributor here. Thanks! I love your aliases. That's exactly how Git Town started. Then people kept adding logic to cover edge cases, abort and undo operations, as well as Github and Bitbucket integration. Soon enough we ended with many hundreds of lines of Bash. Hence the recent rewrite in Go.
Git Town is a strict superset of your tools. Your "topic start" == "git hack". Your "topic pull" and "topic-push" = "git sync" (you always want to run both anyways). Your "topic-finish" = "git ship".
Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing.
The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive.
Good developers engineer repetition away. Great developers share what they build. Hence Git Town.
This tool was built to help stay sane in large high-velocity development teams. In such environments, one can easily spend an hour (or so) each day resolving merge conflicts. Feature branches go out of sync with the main development branch multiple times a day. One has to keep pulling, merging, or rebasing all open branches regularly to avoid more merge conflicts later. Those things require running many Git commands.
Git Town makes all of this quick,easy, and bulletproof. A lot of people have been using it for years and love it for that.
Apparently our documentation doesn't get this across well enough. We'll add more details.
The problem therefore seems to be more accurately described as having the same insights as others, but they arrive later, i.e. "delayed" insights.
Delayed processing could be an effect of delayed context switching, i.e. monotropism [0]. Monotropism can be an indicator of mild autism.
[0] https://en.wikipedia.org/wiki/Monotropism