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

171–180 of 240 posts

Re: 20 years of Git

#171

Post by Ferret7446 »

forrestthewoods wrote: post #71
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…

[flagged]

Everything is a local minima, given that you can't exhaustively prove otherwise for anything beyond the most trivial domains.

Re: 20 years of Git

#173

Post by JimDabell »

forrestthewoods wrote: post #118
wat10000 wrote: post #108

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. 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.

Re: 20 years of Git

#174

Post by vhantz »

qntmfred wrote: post #142
overboard2 wrote: post #100

Earlier quoted context omitted.

What do you mean?

if I'm working in Cursor for example, ideally the entire chat history and the proposed changes after each prompt need to be stored. that doesn't fit cleanly into current git development patterns. I don't want to have to type commit messages any more. If I ever need to look at the change history, let AI generate a summary of the changes at that point. let me ask an LLM questions about a given set (or range) of changes…

You should ask a LLM to create a VCS that will let you not do all these things you don't want to do.

Re: 20 years of Git

#175

Post by uecker »

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, practical, and very efficient no-nonsense tool written in C. This made it much more appealing to many than the alternatives written in C++ or Python.

[1]: https://marc.info/?l=git&m=111366245411304&w=2

Re: 20 years of Git

#176

Post by usefulcat »

squiggleblaz wrote: post #98
forrestthewoods wrote: post #71

Earlier quoted context omitted.

[flagged]

A local minimum is a point in the design space from which any change is an improvement (but there's other designs which would be worse, if they make several larger changes). I think it's hard to make that claim about Git. You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes)…

> something I think it was called VSS

Hmm, maybe Microsoft Visual Source Safe? I remember that. It was notorious for multiple reasons:

* Defaulted to requiring users to exclusively 'check out' files before modifying them. Meaning that if one person had checked out a file, no one else could edit that file until it was checked in again.

* Had a nasty habit of occasionally corrupting the database.

* Was rumored to be rarely or not at all used within Microsoft.

* Was so slow as to be nearly unusable if you weren't on the same LAN as the server. Not that a lot of people were working remotely back then (i.e. using a dial-up connection), but for those who were it was really quite bad.

Re: 20 years of Git

#177

Post by bhasi »

jen20 wrote: post #88
schacon wrote: post #49

Earlier quoted context omitted.

You'll be the first to know when I write it. However, if anything, GitHub sort of killed the mailing list as a generally viable collaboration format outside of very specific use cases, so I'm not sure if I'm the right person to do it justice. However, it is a very cool and unique format that has several benefits that GitHub PR based workflows really lose out on.

By far my biggest complaint about the GitHub pull request model right now is that it doesn't treat the eventual commit message of a squashed commit (or even independent commits that will be rebased on the target) as part of the review process, like Gerrit does. I can't believe I'm the only person that is upset by this!

You are not alone. Coming from Gerrit myself, I hate that GitHub does not allow for commenting on the commit message itself. Neither does Gitlab.

Also, in a PR, I find that people just switch to Files Changed, disregarding the sequence of the commits involved.

This intentional de-emphasis of the importance of commit messages and the individual commits leads to lower quality of the git history of the codebase.

Re: 20 years of Git

#178

Post by fragmede »

ajross wrote: post #87
fragmede wrote: post #58

Earlier quoted context omitted.

but people don't use the file hash, that's internal to git. I go to the centralized repository of repositories at github.com and look up tagged version 1.0.0 of whatever software, which refers to a git tag which references a commit hash (which yes it references a tree object as you said).

"People" don't commonly use them, no. But it's a real and documented API to do this (see e.g. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ). And in any case you had a specific requirement above ("Given a collection of files, but not the git repo they're from, and libgit, I can't say if those files match a git tag hash"), and in fact this can be done!

The git tag hash references a commit. Without the commit metadata, you don't have a tree object and thus don't know any hashes. You can take the files on disk and compute the hash and furthermore you can take that hash and make a tree object. but without the commit, all you can say is you have a tree object, you don't have a tree object for the commit in question to compare it to.

Re: 20 years of Git

#179

Post by ezekiel68 »

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 and Rockstar Games and the number of times dev teams went backwards in versions with digital assets can be counted on the fingers of a single hand.

Re: 20 years of Git

#180

Post by pests »

eterm wrote: post #48
szvsw wrote: post #29

As someone who wrote my first line of code in approx 2010 and used git & GH for the first time in… 2013? it kind of amazes me to remember that Git is only 20 years old. GitHub for instance doesn’t seem surprising to me that is I’ve never used other source control options besides git, and I sometimes wonder if I ever will!

What surprises me more is how young Subversion is in comparison to git, it's barely older. I guess I started software dev at a magic moment pre-git but after SVN was basically everywhere, but it felt even more like it had been around forever vs the upstart git.

Yeah, odd to learn. I remember dipping my toes into source control, playing around with CVS and SVN right around when git was originally announced and it felt so "modern" and "fresh" compared to these legacy systems I was learning.
Post reply on HN