Hacker News Reader

Comment by pjmlp | Hacker News Reader

It is ironic that Linus hates C++ so much, and then proceeds to create what is for all practical purposes, the C++ of source control systems.

View on HN

Complexity is like body odor: you generally don't mind your own.

Git has not been Linus's project for many years.

The Git commit history of Git is nicely browsable here: https://github.com/git/git/graphs/contributors?from=2005-04-...

Indeed, Linus has only one commit in the last 3 years, and is the #28 committer of all time.

Here is his contribution in the last 5 years

https://public-001.gitsense.com/insights/github/repos?p=comm...

The changes were mostly pretty small as well, which would make sense given he has been hands off for quite some time now.

Analogy still applies, though. If a room is smelly to you, you aren't going to hang around. So the people who spend time there are going to be ones comfortable with the funk.

I don't know, have you ever had to use Clear Case? git seems rather lean in comparison.

Yes, plenty of times and never had to redo my ClearCase configuration from scratch.

To be fair, if you mean that these changes are “bloat” and that git should be kept “simple” (not easy but non-complex), I don’t think this has much to do with Linus, because as far as I know he’s no longer involved in the development of git.

He was "scratching his own itch" (see http://www.catb.org/esr/writings/homesteading/cathedral-baza...).

Git was written to meet the version control requirements of the Linux kernel. It works well for that project's needs which are an outlier for most development needs unless you are working at FAANG scale.

Git is a perfect match our project's needs, which are so far from FAANG scale that it would be a joke to even compare them.

In our case, fully distributed development (no developers live or work within 1000 miles of each other), public repository, welcoming 3rd party PRs, strong use of topic branches, fully rebase-not-merge workflow. 600k lines of C++, 21 year history, on the order of 100 contributors, 2-3 core developers at any point in time.

There were other solutions, much less complex to deal with than git, but hey, they lacked the luxury of being an hard requirement to deal with Linux kernel and related eco-system.

I've used, over the years, RCS, SCCS, CVS, SVN, Bitkeeper and Perforce. I would not trade any of them for git at this point in time, primarily due to the way that git allows for both net-connected and disconnected development without any change in the workflow.

I see you left mercurial out of the list.

99% of developers that have to deal with git complexity aren't working at FAANG scale.

Kind of ironic to say "FAANG scale" here, since Google notoriously uses an enormous monorepo, and Facebook uses mercurial and has done considerable work to scale it.

Git is very simple. It's the UI that is a bit messy.

C++ is by no means simple.

What would you recommend using instead of git?

(Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)

I can't recommend pijul, but I can recommend keeping an eye on it. Pierre-Étienne Meunier is a ferociously smart guy, and he's convinced me that patches are the correct way to build a VCS, rather than snapshots.

I catch up on a forum a few times a year, asking myself if it's ready for me to switch a repo or two over and see how it goes. So far I have to answer no, but I'm hoping it's just a matter of time.

Pijul is probably OK to use now:

https://pijul.org/posts/2021-06-28-two-changes/

Like a new filesystem, you should have a backup system in place if you use this, but the system is being well tested.

If I had the choice just mercurial or yes, Subversion does just fine, it is anyway how 99% of people actually use git.

The Fortran of sccs surely?

This should be the top comment!

Reply on news.ycombinator.com