What comes after Git

That’s a complete non sequitur. Everything we learn changes the way we view the world. You cannot make version control software without a data model that needs to be learned. Git’s model is very easy to visualize.

Do you use GitHub? Do you work with a team? Did you really review other alternatives and try them out?

Personally, I’m mostly fine with Git.

But I started off with MPW Projector[0], so it's all sunshine, after that...

The “UX” doesn’t bother me, as it’s a fairly classic CLI application. Any “UI” is provided by apps that are written over the CLI. That’s a common pattern in development.

I use SourceTree, for the most part, with occasional drops into CLI, for specialized tasks.

Not perfect, but adequate. I do not use the Git integration in Xcode. I find it to be inconsistent and buggy (like many Xcode features).

I have found that submodules are all but worthless, which sucks, because I feel that they really are the best way to tag aggregate codebases. From what I understand, this is because of the author’s workflow. If submodules worked like package managers, that would be wonderful.

In my experience, I find sparse checkouts to be a bit “kludgy.” I find it annoying to have to check out an entire repo, for a single file (my testing code usually dwarfs the implementation code, in my packages).

Perforce used to be good at specifying “only what is needed” workspaces.

One aspect of VSS (dating myself —no one else will) that was very cool, was the ability to specify “artificial” workspaces.

You could create a workspace that aliased files from multiple workspaces into a new aggregate. When you modified and checked in work, it could be doled out to several different repos.

That’s pretty hairy. It would be difficult to implement safely.

Git has changed the way I work. As time has gone on, I have moved away from using feature and release branches, to using tags on a single mainline.

I think forks and PRs are great things, but they aren’t actually native Git features.

[0] http://preserve.mactech.com/articles/mactech/Vol.14/14.06/Ve...

>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level.

I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.

Kubernetes didn't brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it's just a drop in the huge ocean of OSS. Maybe level in this context refers to 'gitops' which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.

There are a couple of problems with this in my experience. People who have done computer science or systems/OS programming in a lower level language like C are really comfortable with concepts like pointers/references/links, objects, trees etc. But there are loads of programmers who don't speak this language at all. When I try to explain that almost everything is immutable and append-only and they are only mutating a single reference called HEAD it just doesn't make sense.

The other thing is, like you say, git itself is a terrible way to learn these concepts. A command line interface is great for expressing operations, but the state, before and after, is basically invisible. I think this might be especially hard for more visual people. When I was learning data structures drawing them out and "seeing" the structure was vitally important and I know it's not just me because computer science books are filled with pictures.

I really want there to be a GUI I can recommend people to use for git, but I'm not aware of a good one. I use magit which helps a lot, but I can't recommend that to most people. All the other GUIs I've seen are just about doing command line stuff with a mouse.