Live data from Hacker News

20 years of Git

blog.gitbutler.com

161–170 of 240 posts

Re: 20 years of Git

#161

since it seems it has been forgotten, remember the reason Git was created is that Larry McVoy, who ran BitMover, which had been donating proprietary software licenses for BitKeeper to core kernel devs, got increasingly shirty at people working on tools to make BK interoperate with Free tools, culminating in Tridge showing in an LCA talk that you could telnet to the BK server and it would just spew out the whole histo…

I think that was the first time I ever saw Tridge deliver a conference presentation and it was to a packed lecture theatre at the ANU. He described how he 'hacked' BitKeeper by connecting to the server via telnet and using the sophisticated hacker tools at his disposal to convince Bitkeeper to divulge its secrets, he typed:

help

The room erupted with applause and laughter.

Re: 20 years of Git

#162
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

Another alternative is the patch-theory approach from Darcs and now Pijul. It's a fundamentally different way of thinking about version control—I haven't actually used it myself but, from reading about it, I find thinking in patches matches my natural intuition better than git's model. Darcs had some engineering limitations that could lead to really bad performance in certain cases, but I understand Pijul fixes that.

I was a bit confused about the key point of patch-based versus snapshot-based, but I got some clarity in this thread: https://news.ycombinator.com/item?id=39453146

Re: 20 years of Git

#163
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

[flagged]

Mercurial had its chance, and it blew it by insisting that the history is immutable and branches are heavy-weight objects (SVN-style). Turns out that's not what people want, so git won.

(And the fact that Mercurial supports history editing _now_ is irrelevant, that ship has long sailed.)

Re: 20 years of Git

#164
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

I just wish they'd extend git to have better binary file diffs and moved file tracking. Remembering the real history matters, because preserving history is valuable by itself, but I'm also really glad that VCS is for most people completely solved, there's nothing besides Git you have to pay attention to, you learn it once and use it your whole career.

> I just wish they'd extend git to have better binary file diffs

It's not built-in to git itself, but I remember seeing demos where git could be configured to use an external tool to do a visual diff any time git tried to show a diff of image files.

> and moved file tracking.

Check out -C and -M in the help for git log and blame. Git's move tracking is a bit weirder than others (it reconstructs moves/copies from history rather than recording them at commit), but I've found it more powerful than others because you don't need to remember a special "move" or "copy" command, plus it can track combining two files in a way others can't.

Re: 20 years of Git

#165
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

[flagged]

> Git is for hobby side projects. Perforce and Sapling are for adult projects.

The numbers I've seen say git has about 87-93% of the version control market share. That's just one of many reasons I think it is safe to say most professional developers disagree with you. I can understand someone prefering Perforce for their workflow (and yes, I have used it before). But saying Git is only "for hobby side projects" is just ridiculous. It has obviously proven its value for professional development work, even if it doesn't fit your personal taste.

Re: 20 years of Git

#166

Earlier quoted context omitted.

In my 25ish years I’d professional dev, I’ve used git for about 15 of them. I’ve never used Perforce and never even heard of Sapling. It’s very likely that most if not all of the software stack you’re using to post your comment is managed with git.

I am keenly aware of how common Git is. A whole generation of programmers have only ever known Git and GitHub. They assume that since it is the standard it must be good. This is a fallacy. Bad things can become popular and become entrenched even when better things exist. Replacing Git today would require something not just a little better but radically better. Git was always worse than Mercurial. It won because of Gi…

> Git was always worse than Mercurial.

hard disagree. Git was always way better than Mercurial.

> It won because of GitHub.

I and most of the developers I have worked with over the years all used git for many years before ever even trying GitHub. GitHub obviously has helped adoption, but I'm not convinced that git would not have won even if GitHub had never existed.

Re: 20 years of Git

#167

Earlier quoted context omitted.

So none of the stuff you’re using qualifies as “adult projects”? I don’t object to saying we can do better than git. But saying git “is for hobby side projects” is ridiculous. It’s fine for serious projects.

Depends on how snarky I’m feeling. I’m not sure that webdev counts as wearing big boy pants if I’m feeling frisky! It’d be interesting to analyze how much of the stack used Git as its source of truth versus being mirrored by a BigTech adult VCS! Git sucks for serious projects. It’s certainly what many people use. But I don’t think “we can do better” is a strong enough statement. Git is bad and sucks. It’s functional…

> Git sucks for serious projects.

again, hard disagree. I work on serious projects all day long. Git is fabulous for serious projects.

Re: 20 years of Git

#168
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

Don’t forget Fossil, which started around the same time…

https://fossil-scm.org/home/doc/trunk/www/history.md

Re: 20 years of Git

#169
post #67

> I started using Git for something you might not imagine it was intended for, only a few months after it’s first commit I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used (especially running it from a Linux workstation). So I wrote a few scripts that would let me mirror a directory into a git repo, do a…

> I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used

Ah, ClearCase! The biggest pain was in your wallet! I saw the prices my company paid per-seat for that privilege -- yikes!

Re: 20 years of Git

#170
post #120
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

> There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. What? > Git isn’t just plain wonderful, and in my view, it’s not inevitable either. I mean, the proof is in the pudding. So why did we end up with Git? Was it just dumb luck? Maybe. But I was there at the start for both Git and Mercurial (as I comment elsewh…

Good point. Git succeeded in the same way that Unix/Linux succeeded. Yes, it sucks in many ways, but it is flexible and powerful enough to be worth it. Meanwhile, something that is "better" but not flexible, powerful, or hackable is not evolutionarily successful.

In fact, now that I've used the term "evolution", Terran life/DNA functions much the same way. Adaptability trumps perfection every time.

Post reply on HN