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

141–150 of 240 posts

Re: 20 years of Git

#141

Post by zerocrates »

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)…

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

I think you meant "worse" for that first "better."

Re: 20 years of Git

#142

Post by qntmfred »

overboard2 wrote: post #100
qntmfred wrote: post #46

I think the git usage patterns we've developed and grown accustomed to are proving inadequate for AI-first development. Maybe under the hood it will still be git, but the DX needs a huge revamp.

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 if I need to. we need a more natural branching model. i don't want to have to create branches and switch between them and merge them. less typing, more speaking.

Re: 20 years of Git

#143

Post by mdaniel »

rdtsc wrote: post #105
zahlman wrote: post #94

Earlier quoted context omitted.

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

I may be misremembering but c vs python was a part of it. I don't think Linus thought too highly of python, or any interpreted languages, except shell perhaps, and didn't want to deal with installing and managing python packages.

> and didn't want to deal with installing and managing python packages.

Based on the fact that ecosystem torpedoed an entire major version of the language, and that there are a bazillion competing and incompatible dep managers, it seems that bet turned out well

Re: 20 years of Git

#144

Post by aseipp »

martinvonz wrote: post #113
aseipp wrote: post #93

Earlier quoted context omitted.

I don't know if it's the only or original reason, but one nice consequence of the reverse hex choice is that it means change IDs and commit IDs have completely different alphabets ('0-9a-f' versus 'z-k'), so you can never have an ambiguous overlap between the two. Jujutsu mostly doesn't care about the real "format" of a ChangeId, though. It's "really" just any arbitrary Vec and the backend itself has to define in som…

Yes, it was to avoid ambiguity between the two kinds of IDs. See https://github.com/jj-vcs/jj/pull/1238 (see the individual commits).

Interesting, that was just a few short months before I showed up. :)

Re: 20 years of Git

#145

Post by cyberax »

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…

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

Linus absolutely had a couple of brilliant insights:

1. Content-addressable storage for the source tree.

2. Files do not matter: https://gist.github.com/borekb/3a548596ffd27ad6d948854751756...

At that time, I was using SVN and experimenting with Hg and Bazaar. Both were too "magical" for me, with unclear rules for merging, branching, rebasing.

Then came git. I read its description "source code trees, identified by their hashes, with file content movement deduced from diffs", and it immediately clicked. It's such an easy mental model, and you can immediately understand what operations mean.

Re: 20 years of Git

#146

Post by phire »

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…

I do think an open source, distributed, content addressable VCS was inevitable. Not git itself, but something with similar features/workflows.

Nobody was really happy with the VCS situation in 2005. Most people were still using CVS, or something commercial. SVN did exist, it had only just reached version 1.0 in 2004, but your platforms like SourceForge still only offered CVS hosting. SVN was considered to be a more refined CVS, but it wasn't that much better and still shared all the same fundamental flaws from its centralised nature.

On the other hand, "distributed" was a hot new buzzword in 2005. The recent success of Bittorrent (especially its hot new DHT feature) and other file sharing platforms had pushed the concept mainstream.

Even if it wasn't for the Bitkeeper incident, I do think we would have seen something pop up by 2008 at the latest. It might not have caught on as fast as git did, but you must remember the thing that shot git to popularity was GitHub, not the linux kernel.

Re: 20 years of Git

#147

Post by rdtsc »

mdaniel wrote: post #143
rdtsc wrote: post #105

Earlier quoted context omitted.

I may be misremembering but c vs python was a part of it. I don't think Linus thought too highly of python, or any interpreted languages, except shell perhaps, and didn't want to deal with installing and managing python packages.

> and didn't want to deal with installing and managing python packages. Based on the fact that ecosystem torpedoed an entire major version of the language, and that there are a bazillion competing and incompatible dep managers, it seems that bet turned out well

I like Python and hate to admit it but you’re right.

Re: 20 years of Git

#148

Post by mdaniel »

exe34 wrote: post #22
WalterBright wrote: post #17

Earlier quoted context omitted.

Git hasn't quite taken the step of making the hash the URL you use to download a file, any file, and be assured it is exactly what you thought it was, as the hash of the file must match its URL. This is currently done in a haphazard way, not particularly organized.

git over ipfs then?

I believe that's approximately what this is trying to do https://radicle.xyz/#:~:text=radicle%20is%20an%20open%20sour... although evidently using a custom protocol not ipfs itself

Re: 20 years of Git

#149

Post by tarasglek »

wiktor-k wrote: post #9
jmclnx wrote: post #4

Yes, still odd, but I can deal with it. FWIW, I just found out you can sign commits using ssh keys. Due to how pinentry + gnupg + git has issues on OpenBSD with commit signing, I just moved to signing via ssh. I had a workaround, but it was a real hack, now no issues! 20 years, wow seems like yesterday I moved my work items from cvs to git. I miss one item in cvs ($Id$), but I learned to do without it.

Oh yeah, SSH signing is incredible. I've also migrated to it and didn't look back. A couple of differences: - it's possible to specify signing keys in a file inside the repository, and configure git to verify on merge ( https://github.com/wiktor-k/ssh-signing/ ). I'm using that for my dot config repo to make sure I'm pulling only stuff I committed on my machines. - SSH has TPM key support via PKCS11 or external agent…

Wow that allowed signers feature is cool. should pair nicely with ssh key support in sops
Post reply on HN