Spending $17 million to replace git

[bakul]

Was it Barnum who said no one ever went broke overestimating the stupidity of the American public. (Meaning USA).

It was Mencken who wrote “No one ever lost money underestimating the intelligence of the great masses of the plain people”. Clearly an elitist!

Oh, and by uneducated, I don't mean no college, this level of English is learned, or should be learned, well before then. And college doesn't guarantee education or brains. Lots of stupid people with college degrees are posting their ignorance for all to see. And many of them, if wealthy, went to supposedly good colleges.

“Some people get an education without going to college. The rest get it after they get out.” -- Mark Twain

 

[kent_dorfman766]

It's all smoke and mirrors that indicates symptoms of a much larger problem: the quest to relegate programmers to being interchangeable mindless cogs that can be assigned any task that comes along in a CI pipeline and expect it to be done in the time between scrums, while elevating the business stakeholders to a godlike status where they are neither expected nor required to make decisions and then own those decisions...Let's put all the burden on the devs and then treat them like assembly line workers. CHOP! CHOP! I mean it's just coding. How hard can it be?

Traditional code management tools are totally adequate if you follow honorable predictive development paradigms like waterfall, iterative or V shaped (or even hybrid)...and force business owners to sign off on decisions then accept consequences of their poor decisions in terms of lost productivity...whereas under the current AGILE scam stakeholders are insulated from the consequences of their decisions (or lack thereof), while coders lose their minds and accomplish nothing to add intellectual value to the effort.

But I'm not bitter... (maniacal HAHA)

 

[CShell]

It's all smoke and mirrors that indicates symptoms of a much larger problem: the quest to relegate programmers to being interchangeable mindless cogs that can be assigned any task that comes along in a CI pipeline and expect it to be done in the time between scrums, while elevating the business stakeholders to a godlike status where they are neither expected nor required to make decisions and then own those decisions...Let's put all the burden on the devs and then treat them like assembly line workers. CHOP! CHOP! I mean it's just coding. How hard can it be?

Wait... wait a minute...

You sound like... you do software development !

 

[ShelLuser]

I have always considered git to be a pain in the rear. We used it cause others used it and we had to interface to them. I think "them" used it for the same reason--other people used it, not because they liked it.

If git was that good, why are people going to spend $17 million to replace git

I can definitely respect that, but at the same time you can also turn this around: if Git wasn't all that great then why did it gain such a massive userbase?

Now, I obviously don't know how you guys are using Git but as a die-hard Git fan(boy?) myself I can't help but wonder if it's really Git that's bugging you, or one of the many Git frontends? At the time of writing I do a lot of Python development using VS Code, and of course we're using a Git repository.

So here's the thing... I can't stand the (severe) limitations which I experience when using the Git frontend (courtesy of the Git extension?). I also don't really appreciate the way they're "dumbing things down" (for example: "sync" vs. "pull and push (separate)". As a result I pretty much always keep a PowerShell pane (or window) open (" ctrl + ~") and prefer to type out my commands manually.

However... those frustrations of mine are fully geared towards the plugin, but most definitely not Git itself.

Fair disclaimer... I'm not overreacting when I claim to be a bit of a fanboy... I even use Git to maintain a full retention of my server configuration(s). Even 'worse': using submodules (+ recursion!) I can even group those into a "master repository". In other words... One repository to rule them all, and in the configs bind them! Errr, sorry about that

More seriously: I have a "master" repository on my PC which contains repositories (submodules) for all the servers I maintain. Which means... that if I'm told that we need a new virtual host on our main webserver then I can either log on and perform the changes, or ... activate & edit the Apache configuration on my PC and then push those onto the server.

This also helps us to secure and restore things... at top speed. At the time of writing a customer experienced a rather nasty issue (remote intrusion) and we re-installed the whole server. Installing FreeBSD is quick & easy, but restoring all the required configuration sections? Also easy: we simply cloned the main repo onto the server, then cloned the submodules in the specific areas which are under Git control (like: /etc, /usr/local/etc/apache24, /usr/local/logcheck, /usr/local/openssl, etc.). And as a result we got back up & running in no time.

The fun part is that the intruder obviously had no idea, and completely overlooked all the small .git files (we use repo separation?), this also gave us a good idea of everything that got changed, and a collegae of mine (specialized in security) managed to trace these back to a specific rootkit.

But yah.. Git can be so much more than just "simple version control".

 

[rbranco]

More seriously: I have a "master" repository on my PC which contains repositories (submodules) for all the servers I maintain. Which means... that if I'm told that we need a new virtual host on our main webserver then I can either log on and perform the changes, or ... activate & edit the Apache configuration on my PC and then push those onto the server.

This also helps us to secure and restore things... at top speed. At the time of writing a customer experienced a rather nasty issue (remote intrusion) and we re-installed the whole server. Installing FreeBSD is quick & easy, but restoring all the required configuration sections? Also easy: we simply cloned the main repo onto the server, then cloned the submodules in the specific areas which are under Git control (like: /etc, /usr/local/etc/apache24, /usr/local/logcheck, /usr/local/openssl, etc.). And as a result we got back up & running in no time.

The fun part is that the intruder obviously had no idea, and completely overlooked all the small .git files (we use repo separation?), this also gave us a good idea of everything that got changed, and a collegae of mine (specialized in security) managed to trace these back to a specific rootkit.

But yah.. Git can be so much more than just "simple version control".

You're abusing git here because the only file metadata git stores is file permissions, but not owner/group, flags, etc.

 

[ShelLuser]

You're abusing git here because the only file metadata git stores is file permissions, but not owner/group, flags, etc.

I see where you're coming from, but that's the whole point; something covered in "other ways", amongst which sticky bits but mostly mtree(8).

 

[drhowarddrfine]

if Git wasn't all that great then why did it gain such a massive userbase?

Because Linux told Linux users he uses it and so should they and then Linux and everything related switched to it cause Linus did. It's 90% of the reason.
If Linus switched to Mercurial, everyone would be using Mercurial. If Linux switched to systemd.....

 

[ShelLuser]

Because Linux told Linux users he uses it and so should they. It's 90% of the reason.

Fair enough, but then again... the FreeBSD foundation also followed suit, even though one could argue that this decision was a bit controversial considering the license (GPL3). I still recall (and support) the active movement to get rid of GCC in favor of Clang; as far as I recall mostly driven by licensing concerns.

In addition I also don't think that Microsoft would decide to take over GitHub if it wasn't popular either. Which in its turn also leads to another take on all this... Microsoft also isn't quite popular within certain regions, making me also wonder if that might have something to do with some dislike(s) for Git as well. So, a combination of factors so to speak.

 

[drhowarddrfine]

the FreeBSD foundation also followed suit

Some company online once said they had to switch to git because it's what the people they were trying to hire were used to, not because they liked it.

I also don't think that Microsoft would decide to take over GitHub if it wasn't popular

Again, based on popularity Microsoft wants to have their hands where people are and where the code is.

 

[Jose]

Because Linux told Linux users he uses it and so should they and then Linux and everything related switched to it cause Linus did. It's 90% of the reason.
If Linus switched to Mercurial, everyone would be using Mercurial. If Linux switched to systemd.....

I drove the Git adoption at the company where I was working in the early 10s. Linus and Linux had nothing to do with it. Every other place I've worked at since has already been on Git.

 

[ralphbsz]

Linus and Linux had nothing to do with it. Every other place I've worked at since has already been on Git.

Exactly. Just like Linux has an extremely large market share of development systems and servers, git has an extremely high market share. I've worked at a company that had multiple internal systems (each of which was better than git in some respect, worse than others), but than roughly at the same time (~2010) our group switched to git, because it was just easier for software engineers to use or learn (or not have to learn, since most people already knew it). And that was a group that had user perforce (best source control system I know), and before wrote its own, so they were knowledgeable about the field.

My next big company continue to use its own source control system (because none of the other would work at their scale), but software engineers can interface with it through a git frontend, which emulates git very thoroughly. I personally instead used a mercurial frontend, because I strongly dislike the git interfaces, commands, and naming of things.

There is a reason it is called git, and that's because either the person who initially wrote it (Linus) or who caused it to be written (Larry McV or Andy T) are gits. In the case of Linus and Larry I can confirm that. In the case of Tridge, I very much disagree: he's a really nice guy, friendly and helpful, and extremely knowledgeable and hard working. In English, the word git means "A mildly derogatory term for an unpleasant, silly, or annoying person."

 

[mer]

There is a reason it is called git, and that's because either the person who initially wrote it (Linus) or who caused it to be written (Larry McV or Andy T) are gits. In the case of Linus and Larry I can confirm that. In the case of Tridge, I very much disagree: he's a really nice guy, friendly and helpful, and extremely knowledgeable and hard working. In English, the word git means "A mildly derogatory term for an unpleasant, silly, or annoying person."

Ha. I thought "twits" or "suffering from the I-D-10-T errors"

 

[Alain De Vos]

I drove the Git adoption at the company where I was working in the early 10s. Linus and Linux had nothing to do with it. Every other place I've worked at since has already been on Git.

With writing a few "easy git aliases" you can go long way.

 

[bakul]

There is a reason it is called git, and that's because either the person who initially wrote it (Linus) or who caused it to be written (Larry McV or Andy T) are gits.

Hadn't heard that before... From git's initial commit README:

        GIT - the stupid content tracker

"git" can mean anything, depending on your mood.

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronounciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room.
 - "goddamn idiotic truckload of sh*t": when it breaks

I first used git in 2009 or so because the what we had to use (clearcase) was truly horrible. I also wrote some software to move things back and forth between a local git and the centralized clearcase repo but happily I have forgotten all about it!

 

[Jose]

There is a reason it is called git, and that's because either the person who initially wrote it (Linus) or who caused it to be written (Larry McV or Andy T) are gits. In the case of Linus and Larry I can confirm that. In the case of Tridge, I very much disagree: he's a really nice guy, friendly and helpful, and extremely knowledgeable and hard working. In English, the word git means "A mildly derogatory term for an unpleasant, silly, or annoying person."

This might be an apocryphal story, but it amuses me nonetheless. Supposedly Larry McV yanked the Bitkeeper rug out from under Linus because Tridge "reverse engineered" the BK protocol. According to Tridge, this involved telnetting to the BK port and typing "help".

 

[ralphbsz]

This might be an apocryphal story, but it amuses me nonetheless. Supposedly Larry McV yanked the Bitkeeper rug out from under Linus is that Tridge "reverse engineered" the BK protocol. According to Tridge, this involved telnetting to the BK port and typing "help".

That story is correct. But to get the full flavor of it, you need to have met Linus (famously short-tempered) and Larry (not so famous).

 

[bakul]

The thread starting with https://news.ycombinator.com/item?id=9264885 mentions this but in a different form.
See also https://www.tuhs.org/pipermail/tuhs/2024-December/031221.html where Larry says

                                          git is a ginormous step
backwards.  Only one graph, BK had a graph per file so the GCA is
always the correct one, none of this try different ones until you
get one that automerges; since there is only one graph, all you 
get are commit comments, you lose the oh-so-valuable-file-comments
that you need when the crap hits the fan; you lose a boat load of
performance, especially in areas like annotate/blame when the repo
gets big, etc.  Git sucks, it really does.  Linus claims he wrote
it in a week and it shows.

 

[Alain De Vos]

i had large blobs in .git.
The only way to fix it was create a new repository and more everything over except .git
Everything else failed

 

[ralphbsz]

i had large blobs in .git.
The only way to fix it was create a new repository and more everything over except .git
Everything else failed

It turns out when implemented and administered correctly, you can put large binary blobs in source control. Multi gigabytes, no problem. It is even considered a good idea.

When I worked at Google, its source control system had a billion objects in it (source files etc.), took about 50 terabytes to download a full copy (which nobody ever did), and got multiple checkins per second during normal work hours on the US west coast. That was a few years ago, and is already public knowledge.

Oh, and Larry McV has left the computer industry completely, about 10 years ago, and these days does things like landscaping and tractor maintenance. Even in those things, he remains a git, so I try to not interact with him.