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

221–230 of 240 posts

Re: 20 years of Git

#221

Post by davidgl »

pmarreck wrote: post #33
WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

Isn't this basically... a Merkle Tree, the underlying storage architecture of things like git and Nix? https://en.wikipedia.org/wiki/Merkle_tree Except that instead of a GUID, it's just a hash of the binary data itself, which ends up being more useful because it is a natural key and doesn't require storing a separate mapping

Yep, invented in 1979 and also the core data structure of crypto block chains

Re: 20 years of Git

#222

Post by mrlonglong »

waynecochran wrote: post #81
mrlonglong wrote: post #59

When are we moving to SHA256? Some code bases must be getting massive by now sfter 20 years,

Are you worried about hash collisions from different objects? The probability of a collision of N distinct objects with SHA-1 is (N choose 2) * 1 / 2^161. For a trillion objects the probability is about 1.7 x 10^-25. I think we can safely write code without collisions until the sun goes super novae.

It's not that I'm worried about, it's the fact malicious files can be crafted for a particular hash that could replace the original.

Re: 20 years of Git

#223

Post by TorKlingberg »

nocman wrote: post #169
js2 wrote: 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!

I meant to write a blog post titled "What's good about ClearCase" in 2014, and I wish I did because now I've forgotten most of it.

ClearCase is a terrible version control system I wouldn't wish on my worst enemy, but it did have some good points that git still doesn't have. Large binary file support, configuration records, winkin, views.

With various big companies going towards giant monorepos and the local git repo just being a view into the super-centralized repo, I think they will re-invent parts of ClearCase.

Re: 20 years of Git

#224

Post by jordigh »

Epa095 wrote: post #200
jordigh wrote: post #78

Earlier quoted context omitted.

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

The proper way to do that is say, something like "Olivia (Matt)" and then continue. You use the preferred name, and if you need to refer to the deadname to disambiguate, you do it.

If you can avoid the need to disambiguate, you do that too. The name really is dead. You shouldn't use it if at all possible.

Re: 20 years of Git

#225

Post by jordigh »

hitekker wrote: post #157
jordigh wrote: post #78

Earlier quoted context omitted.

[flagged]

Wait a second. You're saying now hg didn't influence git, but how does that fit with your previous comment? > One particular aspect that often gets left out of this creation myth, especially by the author of Github is that Mercurial had a prominent role I'm not sure where you're getting your facts from.

Mercurial had a prominent role in the creation myth. It didn't influence git, but it was there at the same time, for the same reason, and at one time, with an equal amount of influence. Bitbucket was once seen as fairly comparable to Github. People would choose git or hg for their projects with equal regularity. The users were familiar with both choices.

Linus never cared about hg, but lots of people that cared about git at one point would also be at least familiar with some notions from hg.

Re: 20 years of Git

#226

Post by jdougan »

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…

If you haven't seen Larry McVoy's issues with git, I think the list still has some weight.

https://news.ycombinator.com/item?id=40870840

Re: 20 years of Git

#227

Post by WorldMaker »

gugagore wrote: post #162
tikhonj wrote: post #128

Earlier quoted context omitted.

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

The Patch Theory of darcs and CRDTs (and the middle idea of OTs [Operational Transforms]) are all interestingly related in their early research and early cross-communication. It certainly is fascinating that today it is probably easier to ask "Do you ever think you might want a CRDT for source control?" to explain some of why you might want patch-based over snapshot-based, because CRDTs exist in part because it somewhat was started as "what if you could do something like darcs but with general data, not just source control?" It's fascinating which technologies win and in which ways/places/niches.

Re: 20 years of Git

#228

Post by mgarciaisaia »

WalterBright wrote: post #15
WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

I had actually done a writeup on it, and thought I had lost it. I found it, dated 2/15/2002: --- Consider that any D app is completely specified by a list of .module files and the tools necessary to compile them. Assign a unique GUID to each unique .module file. Then, an app is specified by a list of .module GUIDs. Each app is also assigned a GUID. On the client's machine is stored a pool of already downloaded .modul…

Using a hash (content-addressable) instead of a GUID (random ID for each version) is a big difference, though

Re: 20 years of Git

#229

Post by pabs3 »

dspillett wrote: post #207
pabs3 wrote: post #196

Earlier quoted context omitted.

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.

Also, some source files that could otherwise be treated as text⁰ end up effectively being binary blobs because tools don't write them in a stable order, which makes tracking small changes difficult because you can't see that they actually are small changes. A number of XML formats¹, and sometimes JSON & others, have this issue too. ---- [0] for the purposes of change tracking and merging [1] Stares aggressively at SS…

Could you use git pre-commit hooks or something similar to transform the files by deterministically sorting the items at each level?

Diffoscope does something similar, diff sorted stuff first, then if there are no changes, then report that, and show the unsorted diffs.

https://diffoscope.org/ https://try.diffoscope.org/

Re: 20 years of Git

#230

Post by emmelaich »

cryptonector wrote: post #186
emmelaich wrote: post #114

Earlier quoted context omitted.

I watched that whole process with fascination. It was long, careful, thorough ... and chose wrong. A part of me thinks that there was a Sun users aversion to anything Linux related.

> A part of me thinks that there was a Sun users aversion to anything Linux related. It wasn't that. It really was just about file renaming.

Git ignored that particular Gordian knot by ignoring it. Many VCSs agonised over file identity. They overestimated the importance and underestimated its difficulty. It's basically impossible in the general sense.
Post reply on HN