The History of Git | Hacker News Reader

The History of Git

welcometothejungle.com

124 pointswickwavy42 comments

Google seems like a poor example for a company using git. Yes many of their open source projects are under git, but the huge monorepo that holds all the proprietary code works with Piper [0]

[0] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

It should be noted for those who have not worked at google (since piper is proprietary) that it works quite similarly to perforce.

(Early in my gamedev career, I've started with CVS/VSS quickly to switch to p4, then went for 2 years to google using CiTC+g4, then back to gamedev with p4).

Even the tool is called "g4" from "p4", has similar style of commands. The best part is that I can work from any directory ("client" p4 terms - https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef...) and in "g4" they all have virtual (unrealized) view + merges from my changes. What's even more appealing, is that I can do that from home, from a browser - no VPN, just UbiKey + https://cloud.google.com/beyondcorp/ - then I can even start a build (not on my laptop, it's just a dumb terminal at this point). I can later even (try) to debug with interface like https://source.chromium.org/ but my jobs on borg - not real debug, but I can add print statements, and it'll sync with the CL (changelist number) of my pushed binary.

So - this is all cool. But then I never really knew how many people, and how man-hours were behind this coolness..

One of the things I miss about Google, is exactly that dedication to the engineer and make their work not impeded.

I thought it actually was Perforce. (or perhaps once was?)

I'm sorry, I'm getting way too bored in the meeting I'm in atm, but I believe this is false:

> With distributed VCS, a copy of the most current version of the code resides on each developer’s device

There is nothing that can guarantee the copy you have is the latest. Can be very far back, can be forward, can be diverged to hell.

I think that sentence doesn't intend to imply such a guarantee, but instead indicates ideal up to date state of the repo.

In fact that description is even more wrong since every RCS has a copy of the checked out tree -- that's the whole point of an RCS!

With git (why does that article insist on spelling it "Git"?) you have a copy of the whole tree, so every clone can also be a an upstream tree for somebody else if desired.

AFAICT, Git documentation capitalizes the first letter:

> The advantages of Git compared to other source control systems. [0]

> You can learn more about individual Git commands with "git help command". [1]

[0] https://git-scm.com [1] http://man7.org/linux/man-pages/man1/git.1.html

Interesting, old programs like 'rm' only use lower case but new programs like bash and git (or should I say "Bash" and "Git") capitalize the program name sometimes.

Given that Unix (not "unix") inherited case sensitivity from Multics I would expect more consistency in the spelling.

(Clearly I'm focusing on the most important topics in computing!)

You are /technically/ correct... the best kind of correct. A more accurate version of that sentence would be, "With distributed VCS, a copy of the entire code base, including the history of changes, resides on each developer's device"

That’s not correct either. The more accurate version (which is also still wrong) would be: “with distributed VCS, a subset of the entire code base, including history about a subset of changes might reside on a subset of the developers devices and other storage locations” (With a reminder that any set is a subset of itself)

This article is great for attributing Git’s success to not only Linus Torvald’s core creation but also subsequent contributions from Hamano, King, Schindelin, Pearce, and many others [1] in the community. Git’s core architecture was critical but would not have succeeded without the ecosystem that grew around it.

[1]: https://github.com/git/git/graphs/contributors

One technical error in the article was understating the distributed nature of Git:

> With distributed VCS, a copy of the most current version of the code resides on each developer’s device, making it easier for developers to work independently on changes to the code.

Replacing s/most current version/all versions/ gives us the technically correct statement:

> With distributed VCS, a copy of all versions of the code resides on each developer’s device, making it easier for developers to work independently on changes to the code.

Having all versions of code is what allows local branch, rebase, merge, and conflict resolution before pushing those changes to the shared repo.

This reminds be of a talk I watched by Richard Hipp, "Git: Just Say No" [0] where he discusses a "top 10 git enhancements" list, as of the time (4 years ago.) It's a good talk, and caused me to discover Fossil SCM. Sadly I've yet to try/use Fossil, and my teams still use git.

  [0] https://www.youtube.com/watch?v=ghtpJnrdgbo

I'm not convinced by Hipp's claim that storing a repo in a single file (SQLite database) is somehow superior to storing a repo in a filesystem directory than contains many files. What am I missing?

I don't actually remember making that argument. But I will try to reconstruct my thinking...

(1) Keeping an entire repo in a single file is a better abstraction. There is just one file to move around or rename. There is a single icon on your desktop to drag around or double-click on. There is a single file to attach to an email. There is a single file to measure the size of when judging the size of a repository. And so forth.

Lots of programs bundle multiple entities into a single file for convenience like this. For example, a DOCX file is really a ZIP archive containing lots of individual pieces. Would you rather your document be a single DOCX file, or a directory full of the individual pieces. Which would be more convenient to use, do you suppose? How is a VCS repository different from a DOCX file in this respect?

Another way to look at this: Breaking up a repository into a directory full of separate files exposes internal implementation details to the user.

(2) Perhaps I was making the argument that a relational database is better than a key/value database for holding a repository. (A directory full of files is just a kind of key/value database after all.) There are countless reasons why relational databases work better than key/value databases. One example: With Git, given an individual check-in, it is difficult to discover the descendants of that check-in. It is so difficult, in fact, that none of the common Git tools provide that capability, and Git workflows are engineered (perhaps subconsciously) to avoid the need to ever figure out what comes after a specific check-in. But if Git used a relational database to store content, finding the descendants of a check-in would be a fast and simple query.

(3) I/O to a single relational database is faster than I/O to individual files on disk. See https://www.sqlite.org/fasterthanfs.html for details.

Regarding (1), I just ran across an old blog post by Scott Chacon about using git bundles.

http://scottchacon.com/2010/03/10/bundles.html

git-bundle documentation: https://git-scm.com/docs/git-bundle

So can anyone explain no one considered that you might want to ultimately use a different hashing algorithm than sha1?

All hashing algorithms have a shelf life before it becomes feasible to compromise them such that you need to migrate to something more secure.

Yet the Git format seems but built for this are all. No hash versioning, no allowance for multiple hashes and no way you define the hash size such that now it seems like moving on from sha1 is going to be a giant pain.

TCP/IP had this from many years earlier (a version at least). This seems like such a glaring oversight. Or am I missing something?

See this recent article from LWN:

https://lwn.net/Articles/811068/

That contains a link to an early comment from Linux.

It could be that they knew that the hash algorithm was good for uniqueness and they were unconcerned about security. The SHA1 hash provides no security in git, only whether a file has been changed or not.

While collisions have been found in SHA1, it is still a decent hashing algorithm where collisions are extremely unlikely.

> collisions are extremely unlikely

Random collisions are quite unlikely, intentional collisions not so much.

> The SHA1 hash provides no security in git

False. OpenPGP signatures in git depend on the SHA1 hash. Same for someone doing a checkout at a specific hash because they trust it.

> All hashing algorithms have a shelf life before it becomes feasible to compromise them such that you need to migrate to something more secure.

This is at best an unproven conjecture and more likely just plain wrong.

Which doesn't make it any saner for Git to have chosen SHA-1 given its status at the time, (SHA-256 was the right choice then and remains a sound choice now) but it certainly isn't true that there's some cosmic law giving hashing algorithms a "shelf life" in this way.

Linus discussed this in: https://lore.kernel.org/lkml/Pine.LNX.4.58.0504090902170.126...

The key point for me is his note that you have to more than copy the SHA1. That it will have to also be a valid zlib object with a matching header.

Let's begin at the beginning, Chapter da39a3ee5e6b4b0d3255bfef95601890afd80709.

Of course, that's tongue-in-cheek. It all began with e83c5163316f89bfbde7d9ab23ca2e25604af290.

sha1("") == da39a3ee5e6b4b0d3255bfef95601890afd80709

and 'e83c5163316f89bfbde7d9ab23ca2e25604af290' is the inital commit of git itself: https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca...

>random three-letter combination that is pronounceable, and not actually used by any common UNIX command.

>actually

Many native French speakers use 'actually' when they mean 'currently' because of the 'actuellement' false-cognate. This looks like the same mistake but neither Swedish nor Finnish have a word that looks like 'actually' when I machine-translate 'currently'.

Any ideas?

>Many native French speakers use 'actually' when they mean 'currently' because of the 'actuellement' false-cognate.

It's also a false friend in German: "aktuell". Wiktionary states that the Swedish word is based on French or German [0]

"From French actuel, perhaps via German aktuell, from Late Latin actuālis, from Latin āctus + -ālis."

[0] https://en.wiktionary.org/wiki/aktuell#Swedish

In Swedish we have the word "aktuell" which means current (in time).

Actually is also a false friend in Spanish.

That sentence reads fine to me. Possibly for the reasons you listed, which then lead to that usage being common in the language.

Reads like fine English to me. The meaning is "really". As in, he had more favored name ideas, but they were taken.

I am a native Swedish speaker though, so I may share some language blindness with Linus.

I know nothing of Finnish, but, in poking around on Google translate, I found 'nykyinen', commonly translated as 'currently', but sometimes as 'existing'. To rephrase the sentence to say "there is no existing use..." would be a little awkward in English, but would convey the same message.

I felt that in this particular sentence, neither 'actually' nor 'currently' are necessary, but to be sure I wanted to check the context, only to find that this sentence is not currently to be found in the article.

Finn here. I don't think the use of "actually" comes from any Finnish expression specifically but it might be some sort of literary habit that stems from the desire to emphasize how things turned out to be. It's somewhat common in Finnish to say how things turned out, rather than that someone (or you) made it so.

Thinking about it, I might've used the word in a similarly redundant fashion myself occasionally.

I think you’re overthinking it. The first definition in the Oxford Dictionary for “actually” equates it with “really”, a substitution which works fine here.

1. as the truth or facts of a situation; really.

"we must pay attention to what young people are actually doing"

That's definitely a possibility I didn't give the proper consideration. On the other hand, if I wrote that sentence with that intention, I would strip 'actually' it for being unnecessary.

Overthinking? Well I can hardly characterise this tangent as important.

Another anecdata from a Swedish native:

"Actually" is sometimes used purely for effect (affect?) without any reflection on the meaning of it, similar to how "ducking" is used.

I'm imagining "git" wasn't his first try at finding a unique TLA, and the actually is there to signal effort spent.

Wonderful! :o)

Reminds me of the joke about there only being 10 kinds of people in this world, those who understand binary and everyone else. Yours is even more esoteric – well done!

And those who understand gray code :)

What is that font?

I don't know but I don't like it, at least for a long form article.

The history of Git, told with a font that’s only feature is making the letter G unreadable.

https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...

ublock origin lets you disable custom fonts globally or per-site.

Reply on news.ycombinator.com