Git is too hard

Never used it but I had to use ClearCase at work even though I was already proficient in git.

Ugh. The centralized model is better for companies, but ClearCase really makes its best to make your life miserable:

- You have to think twice before modifying a file, because the steps to be able to modify a file can take from 30 seconds (if you already created the activity) to a few minutes (if you have to create it)

- Activities are supposed to be like branches, summing up all the changes. But there is no way to see all changes in one go. It's click everywhere, waiting for the server to reply on each click.

- Because there is no way to display the branch content in any way other than envisioned by IBM, there is no way to discuss a changeset. No pull requests, no exchange, nothing.

- Horrible UI/UX all around. It's slow, it's unreadable, random bugs happen all the time where the only fix is to restart the service, .... and it's expensive.

I'm not advocating for a system that only works when online (although the fully integrated system of Google does sound good), just that it be architectured around a point of centralization. This is the way I'd like to use git:

- A branch created locally will be synhcronized and visible to everyone by default

- A branch that I manually tag as private won't, but it will still be saved on the server

- A branch that has a conflict between me and someone else will be marked locally in some way (maybe a second branch ?)

- Bonus: my working repo and staging area are also synhcronized to the server

OK, we got a powerful and flexible version control system which some people find difficult to use. The solution is to build alternative wrappers/frontends (command-line or GUI) on top of it, which present different takes on the best user interface. The author finds local/remote branching confusing? One could build a small `git` command wrapper that will hide it and have more straightforward branching commands. You can think of current git as an assembly language of version control and develop wrappers/compilers for high-level VC languages of various flavors.

Starting from scratch and building a dumbed-down version control system for simple users vs. kernel developers is not the right approach, IMHO. As they say: "build a system any idiot can use, and only idiots will use it." Or you will end up incrementally adding more and more advanced features to it.

Oddly enough, pianists not knowing how to tune a piano is an anomaly in the music world, as most other artists know their instruments inside and out. The Times did a piece on this just the other day: https://www.nytimes.com/2020/11/12/arts/music/piano-tuning.h...

Bisect is a debugging utility - it helps you do a binary search for the commit which introduced a bug by checking out code at certain commits, having you compile and run it, and tell git if the bug was there or not, and then going back or forward in history until you can identify the 1 commit that caused the bug to appear.

I've never used it, but it sounds like a nice tool of last resort.

> I have to laugh when you say its replacing email.

Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they shifted to mediums better suited. Just this morning I had to FB message a few friends to get their current email addresses, which tells me a lot about who's winning.

Yes, I agree there are times you don't want things unsent. And there are times you do. There are a variety of ways to balance these concerns. But exactly none of them involves saying, "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."

Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel. It reminds me of this Douglas Adams quote:

"I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the natural order of things."

Sure, I get that a lot of people were born after RFC 822, so it seems like the natural order. But the people who wrote the early RFCs weren't thinking that way, and neither should we.