3 ms·

Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonli

Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonlinear and our brains just don't work that way. There isn't a clear vocabulary for intricacies of revision control, yet. And if you can't name something clearly, you can't explain it clearly. The author's idea of putting an abstraction on top of git is the way to go. As an analogy, Git is a great toolbox, but sometimes you need a plumber. I like how apt and apt-get came into being on Ubuntu. The comments about the logical inconsistencies in Gits command line are a clue. When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. But that is also a legacy of Unix/BSD. Consider `du` and `find`. Both have an option for max depth, but is it --max-depth, -maxdepth, --maxdepth, -d, or -m (or even -L for `tree`). There is a lack of consistency that is a rite of passive for Unix/BSD acolytes that even Gnu didn't fix... C'est la vie? Or maybe a /bin rewrite? bahahahaa who am I kidding. There's no question Git is a powerful tool, it just needs to evolve and gain some consistency. And I think the answer is a higher level abstraction. And for the love of Benji, NOT a GUI.

gizmo385 6y ago
> When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. I think what's interesting is that, in the space of programming language development, languages that tend to have a more consistent feel across the language (such as Clojure, Python to some extent) tend to have BDFLs and came from a single person.
- rossdavidh 6y ago
  Python an interesting example because, as the BDFL has ceded more control over development to others, it has been gradually losing some of that consistency.
- SoSoRoCoCo 6y ago
  I know this sounds boring, but I enjoy looking at how programs manage command-line options. There are so many libraries in many languages. Some require structures so that help screens can be autogenerated. Some allow grouping of options `tar xvzf`, some don't require a dash, some have one-dash for short and two dashes for long options. Some require `=` between parameter and value, some (like mbed, npm, yarn and git) have subcommands and sub-subcommands. It is truly fascinating the number of ways command-line parameters have been handled over the last 40 years. I think someone on HN should write a blog post covering the history of CLI options. Wait, I bet there are 50 if I googled...

gizmo385 6y ago

> When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. I think what's interesting is that, in the space of programming language development, languages that tend to have a more consistent feel across the language (such as Clojure, Python to some extent) tend to have BDFLs and came from a single person.

rossdavidh 6y ago
Python an interesting example because, as the BDFL has ceded more control over development to others, it has been gradually losing some of that consistency.
SoSoRoCoCo 6y ago
I know this sounds boring, but I enjoy looking at how programs manage command-line options. There are so many libraries in many languages. Some require structures so that help screens can be autogenerated. Some allow grouping of options `tar xvzf`, some don't require a dash, some have one-dash for short and two dashes for long options. Some require `=` between parameter and value, some (like mbed, npm, yarn and git) have subcommands and sub-subcommands. It is truly fascinating the number of ways command-line parameters have been handled over the last 40 years. I think someone on HN should write a blog post covering the history of CLI options. Wait, I bet there are 50 if I googled...