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

181–190 of 240 posts

Re: 20 years of Git

#181

Post by forrestthewoods »

nocman wrote: post #166
forrestthewoods wrote: post #118

Earlier quoted context omitted.

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.

> Git was always way better than Mercurial.

How is Git better than Mercurial in any way nevermind "always way better". Serious question.

I'd possibly accept "the original Mercurial implementation was Python which was slow". And perhaps that's why Git won rather than GitHub. But I don't think so.

Re: 20 years of Git

#182

Post by forrestthewoods »

nocman wrote: post #167
forrestthewoods wrote: post #152

Earlier quoted context omitted.

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.

I hope that someday you get to experience a VCS tool that doesn't suck.

Re: 20 years of Git

#183

Post by Tomis02 »

talles wrote: post #69

Why did git 'won' over mercurial? Because Github was better than Bitbucket? Or maybe because of the influence of kernel devs?

> Because Github was better than Bitbucket?

Github was more popular than Bitbucke, so git unfortunately won.

Re: 20 years of Git

#184

Post by cryptonector »

bryanlarsen wrote: post #125
cryptonector wrote: post #99

Earlier quoted context omitted.

> What surprises me more is how young Subversion is in comparison to git, it's barely older. Subversion was so awful that it had to be replaced ASAP.

True. Also, Subversion was so great that it very quickly replaced the alternatives that predated it.

Not true. CVS stuck around a while longer.

Re: 20 years of Git

#185

Post by usefulcat »

cryptonector wrote: post #99
eterm wrote: post #48

Earlier quoted context omitted.

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.

> What surprises me more is how young Subversion is in comparison to git, it's barely older. Subversion was so awful that it had to be replaced ASAP.

There were far, far worse things out there than Subversion. VSS, ClearCase, an obscure commercial one written in Java whose name escapes me now..

Subversion was basically a better CVS. My recollection is that plenty of people were more than happy to switch to CVS or Subversion (even on Windows) if it meant they could escape from something as legitimately awful as VSS. Whereas the switch from Subversion to Git or Mercurial had more to do with the additional powers of the newer tools than the problems of the older ones.

Re: 20 years of Git

#186

Post by cryptonector »

emmelaich wrote: post #114
cryptonector wrote: post #96

Earlier quoted context omitted.

I wonder this too. My guess is that he did not like "heavyweight" branching and the lack of cherry-pick/rebase. At any rate that is why I didn't like it back then. Sun Microsystems (RIP) back then went with Mercurial instead of Git mainly because Mercurial had better support for file renames than Git did, but at Sun we used a rebase workflow with Mercurial even though Mercurial didn't have a rebase command. Sun had b…

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.

Re: 20 years of Git

#187

Post by jen20 »

schacon wrote: post #91
jen20 wrote: post #88

Earlier quoted context omitted.

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!

If this is something you're interested in, you may want to try the patch-based review system that we recently launched for GitButler: https://blog.gitbutler.com/gitbutlers-new-patch-based-code-r...

This does look interesting! I’ll take a closer look.

Re: 20 years of Git

#188

Post by forrestthewoods »

JimDabell wrote: post #173
forrestthewoods wrote: post #118

Earlier quoted context omitted.

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.

> People wanted Git

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

Re: 20 years of Git

#189

Post by johnisgood »

frutiger wrote: post #97
kbolino wrote: post #86

Earlier quoted context omitted.

The RFC defining them says they're the same and has since the earliest draft I can find, also from 2002. You should offer more explanation when you take a stance contrary to what is well documented.

A hash is not globally unique. I'm not sure what more explanation is needed.

Check my other comment as to how GUIDs are created in many ioquake3 forks. They MD5 hashed a randomly generated file.

Theoretically speaking, UUIDs have a semantic guarantee that each generated identifier is unique across all systems, times, and contexts, whereas cryptographic hashes are deterministic functions (i.e. they produce the same output for the same input), there is no inherent randomness or timestamping, unless you deliberately inject it such as the way ioquake3 forks did with GUID.

UUIDv4's output size is 122 bits usable, so 1 in 2^122 chance of collision, whereas SHA-512 and BLAKE2b has 512 bits, which has a 2^256 collision resistance, bound by the birthday problem.

In any case, SHA-256, SHA-512, BLAKE2b (cryptographic hashes) are unique in practice, meaning they are extremely unlikely to collide, more so than UUIDv4, despite UUIDv4 being non-deterministic, while cryptographic hashes are deterministic.

Of course, you should still know when to use cryptographic hashes vs. UUIDs. UUIDs are good for database primary keys, identifying users globally, tracking events, and the rest, such as verifying file content, deduplicating data by content, and tamper detection is the job of a cryptographic hash.

But to get to the chase: GUIDs (Globally Unique Identifiers) are also known as UUIDs (Universally Unique Identifiers), so they are the same!

I hope this answers OP's (kbolino) question. He was right, GUIDs are the same as UUIDs. Parent confused GUIDs with cryptographic hashes, most likely.

---

FWIW, collision resistance (i.e. birthday bound) is not improved by post-quantum algorithms. It remains inherently limited by 2^{n/2}, no matter what, as long as they use hashing.

---

TL;DR: GUIDs (Globally Unique Identifiers) are also known as UUIDs (Universally Unique Identifiers), so they are the same, i.e. GUIDs and UUIDs are NOT different!

Re: 20 years of Git

#190

Post by akoboldfrying »

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…

I think this conflates "non-source" with "large". Yes, it's often the case that source files are smaller than generated output files (especially for graphics artifacts), but this is really just a lucky coincidence that prevents the awkwardness of dealing with large files in version control from becoming as much of a hassle as it might be. Having a VCS that dealt with large files comfortably would free our minds and open up new vistas.

I think the key issue is actually how to sensibly diff and merge these other formats. Levenshtein-distance-based diffing is good enough for many text-based formats (like typical program code), but there is scope for so much better. Perhaps progress will come from designing file formats (including binary formats) specifically with "diffability" in mind -- similar to the way that, say, Java was designed with IDE support in mind.

Post reply on HN