Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20 years of Git

blog.gitbutler.com

Post reply on HN
Print view View original

191–200 of 240 posts

Re: 20 years of Git

#191

Post by globular-toast »

> patches and tarballs workflow is sort of the first distributed version control system - everyone has a local copy, the changes can be made locally, access to "merge" is whomever can push a new tarball to the server.

Nitpick, but that's not a distributed workflow. It's distributed because anyone can run patch locally and serve the results themselves. There were well known alternative git branches back then, like the "mm" tree run by Andrew Morton.

The distributed nature of git is one of the most confusing for people who have been raised on centralised systems. The fact that your "master" is different to my "master" is something people have difficulty with. I don't think it's a huge mental leap, but too many people just start using Gitlab etc. without anyone telling them.

Re: 20 years of Git

#192

Post by JimDabell »

forrestthewoods wrote: post #188
JimDabell wrote: post #173

Earlier quoted context omitted.

> Git was always worse than Mercurial. It won because of GitHub. If MercurialHub had been invented instead we’d all be using that and would be much happier. MercurialHub was invented. It’s called Bitbucket, it was founded around the same time as GitHub, and it started out with Mercurial. People wanted Git, so Bitbucket was forced to switch to Git.

> People wanted Git No. If Bitbucket competed with MercurialHub then MercurialHub would still have won and we’d all be much happier today.

Bitbucket was your desired MercurialHub. They supported Mercurial first. Then they added Git support because people wanted Git. At that point, Bitbucket users could choose between Git and Mercurial. They chose Git, so much so that Bitbucket stopped supporting Mercurial.

Look, I get that you hate Git, but people had the choice of using Mercurial or Git – on the same platform even – and they overwhelmingly chose Git. You claiming that Mercurial would win in a fair fight ignores the fact that that fight did actually happen and Mercurial lost.

Re: 20 years of Git

#193

Post by forrestthewoods »

JimDabell wrote: post #192
forrestthewoods wrote: post #188

Earlier quoted context omitted.

> People wanted Git No. If Bitbucket competed with MercurialHub then MercurialHub would still have won and we’d all be much happier today.

Bitbucket was your desired MercurialHub. They supported Mercurial first. Then they added Git support because people wanted Git. At that point, Bitbucket users could choose between Git and Mercurial. They chose Git, so much so that Bitbucket stopped supporting Mercurial. Look, I get that you hate Git, but people had the choice of using Mercurial or Git – on the same platform even – and they overwhelmingly chose Git. Y…

You’re acting like the only different between GitHub and Bitbucket was the choice of VCS tool. That’s obviously not even remotely true. GitHub was a superior platform that was more pleasant to use than Bitbucket. The choice of Git had nothing to do with that.

GitHub won. Not Git. IMHO.

Re: 20 years of Git

#194

Post by JimDabell »

forrestthewoods wrote: post #193
JimDabell wrote: post #192

Earlier quoted context omitted.

Bitbucket was your desired MercurialHub. They supported Mercurial first. Then they added Git support because people wanted Git. At that point, Bitbucket users could choose between Git and Mercurial. They chose Git, so much so that Bitbucket stopped supporting Mercurial. Look, I get that you hate Git, but people had the choice of using Mercurial or Git – on the same platform even – and they overwhelmingly chose Git. Y…

You’re acting like the only different between GitHub and Bitbucket was the choice of VCS tool. That’s obviously not even remotely true. GitHub was a superior platform that was more pleasant to use than Bitbucket. The choice of Git had nothing to do with that. GitHub won. Not Git. IMHO.

The only difference between using Bitbucket with Mercurial and using Bitbucket with Git was the choice of VCS tool. And people chose Git.

> If MercurialHub had been invented instead we’d all be using that

This existed. We aren’t.

Re: 20 years of Git

#195

Post by pabs3 »

jordigh wrote: 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…

The file-tree-snapshot-ref structure is pretty good, but it lacks chunking at the file and tree layers, which makes it inefficient with large files and trees that don't change a lot. Modern backup tools like restic/borg/etc use something similar, but with chunking included.

Re: 20 years of Git

#196

Post by pabs3 »

ezekiel68 wrote: post #179
jordigh wrote: 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…

>And the git data structure... falls apart for large files. I'm good with this. In my over 25 years of professional experience, having used cvs, svn, perforce, and git, it's almost always a mistake keeping non-source files in the VCS. Digital assets and giant data files are nearly always better off being served from artifact repositories or CDN systems (including in-house flavors of these). I've worked at EA Sports a…

Non-source files should indeed never be in the VCS, but source files can still be binary, or large, or both. It depends on how you are editing the source and building the source into non-source files.

Re: 20 years of Git

#197

Post by oblio »

uecker wrote: post #175
jordigh wrote: 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…

A lot of the ideas around git were known at this time. People mentioned monotone already. Still, Linus got the initial design wrong by computing the hash of the compressed content (which is a performance issue and also would make it difficult to replace the compression algorithm). Something I had pointed out early [1] and he later changed it. I think the reason git then was successful was because it is a small, pract…

And because of Linux offering free PR for git (especially since it was backed by the main Linux dev).

Human factors matter, as much as programmers like to pretend they don't.

Re: 20 years of Git

#198

Post by sampo »

zahlman wrote: post #94
jordigh wrote: 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…

Do you happen to know what Linus didn't like about Mercurial?

A lot of things in Mercurial kind of geared you towards using it more like Subversion was used. You pretty much could use Mercurial just like git was, and is, used, but the defaults didn't guide you to that direction.

One bigger difference I can think of is, Mercurial has permanently named branched (branch name is written in the commit), whereas in git branches are just named pointers. Mercurial got bookmarks in 2008 as an extension, and added to the core in 2011. If you used unnamed branches and bookmarks, you could use Mercurial exactly like git. But git was published in 2005.

Another is git's staging area. You can get pretty much the same functionality with repeatedly using `hg commit --amend` but again, in git the default gears you towards using the staging approach, in Mercurial you have specifically search for a way to get it to function this way.

Re: 20 years of Git

#200

Post by Epa095 »

jordigh wrote: post #78
schacon wrote: post #73

Earlier quoted context omitted.

I'm curious why you think hg had a prominent role in this. I mean, it did pop up at almost exactly the same time for exactly the same reasons (BK, kernel drama) but I don't see evidence of Matt's benchmarks or development affecting the Git design decisions at all. Here's one of the first threads where Matt (Olivia) introduces the project and benchmarks, but it seems like the list finds it unremarkable enough comparat…

[flagged]

> Please don't do that. Don't deadname someone.

Is this not a case where it is justified, given that she at that time was named Matt, and it's crucial information to understand the mail thread linked to? I certainly would not understand at all without that context.

Post reply on HN