Hacker News Reader

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.

> 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.

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.

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...

> Git is the democracy of programming: it is the worst tool for version control, except all those other tools that have been tried from time to time.

https://blog.carlmjohnson.net/post/2018/git-gud/

> If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault.

Ready to be downvoted into oblivion for this, but: This is how a lot of the Linux/FOSS community is so it makes sense that Git is too, sadly.

Things have gotten a lot better with the attitude these days, but you know it's bad when StackOverflow needs to issue guidelines on being polite and how to answer questions without being rude/condescending.

What do you recommend in these cases? People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". My mind goes straight to VCS, but git is too hard to get them quickly up and running.

I tried SVN one time, which is a little simpler, but still didn't catch on with the person I was showing it to.

> People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files".

IMO nothing remotely like version control nor anything that requires a command line is going to click for someone in a non-technical field.

If you

    rm -r some_common_dir/

or

    echo foo > important_file.txt

that would also be perceived as your fault. And yet, command shells are pretty good software.

As for non-devs editing the same document - unless that document is text (which typically it isn't for non-devs), I would probably not use git on them either.

> And yet, command shells are pretty good software.

This is a contentious statement. Fred Brooks himself calls the separate command language, which began with JCL on OS/360, a mistake.

Now that is interesting! Do you remember where he said this?

In this interview at least: https://cacm.acm.org/magazines/2015/11/193333-an-interview-w...

> Good software is not like that

You can't just say this without providing an example of what you think is good software, as, after all, good and bad are subjective and not agreed upon by all people for all things, as evidenced in this thread.

Anu (successor of Pijul), of course. ;)

https://news.ycombinator.com/item?id=25001539

Mercurial, Pijul, Bazaar, Subversion

In fact, it's every fucking version control system other than Git.