Git is the next Unix | Hacker News Reader

Git is the next Unix

advogato.org

137 pointskmt34 comments

This is the original entry:

http://alumnit.ca/~apenwarr/log/?m=200801#31

Same person who brought us "Tracking an entire Windows sytem inside Git" last month:

http://news.ycombinator.com/item?id=455320

Note the title could be construed the wrong way, the author means it is the next unix only as an analogy: it's a new, underlying platform where atomic building blocks can be combined and hooked up by higher level programs to do a lot of great things.

Any title describing success or rants on GIT, Lisp, Haskell, or Ruby gets automatic up-votes.

And maybe it could be stretched to be "the next Linux." Still wrong.

I read the article before upvoting it, sounds like you didn't since he made a pretty clear analogy between GIT and Unix that wasn't just link bait.

I hope you read any article on Hacker News before upvoting it.

More than that I hope you read the comments too, because if you aren't an expert that might be one here who can help debunk snake oil before you upvote.

I've been caught a few times reading a story, upvoting it, and then finding a well written comment a moment later about what total tosh it is.

... and agreed with the comment?

Yes, that happens all the time to me, too. Comments here are often much better argued than the linked articles. And I guess it should be no surprise to you that even well-written articles can be complete tosh.

It seems like any second order discussion of behavior on Hacker News that takes place in the comments is now getting down modded. I'm a bit worried about the trend towards groupthink this encourages. Perhaps the user did not read the article, krschultz, but users up voting your comment without hearing a response from the previous commenter is just as bad as your assumption. The fact that your snarky response has gotten up voted seems suspect. Regardless, discussion about the community itself is healthy, hopefully the HN community realizes that and can sustain it. To be clear, I'm not suggesting that the comment should not be down modded at all, just questioning the reason for which you claim you down modded. (I'm curious to see if this comment will be down modded as well)

OK, I clicked on the advogato.org link, and I confirm it is the same entry as the OP of this thread gave. It is a rant on Git, it is very shallow, it compares Git with an operating system family and filesystems.

I stand by my comment, in fact it probably was very tame. This is shallow crap linkbait trash without any real substance.

Git is great and it blew and expanded my mind.

But I have some questions for the the experts. Is git really a fantastic achievement, or is the praise for git coming from people who are not experts in source control (+)?

Based on my cursory readings, it appears that the concepts Git uses (dag, everything is a node, tree snapshotting etc) existed in Bitkeeper.

(+): I ask this because I've repeatedly found that what looks like a big conceptual leap to outsiders is actually a gradual evolution. Examples: I first thought RISC was a big leap, but on reading up the technical papers later, I realized that it was made of lots of innovations by lots of people.

I think your hypothesis is correct, but that doesn't make Git any less of an achievement. Certainly it is the product of technologies that existed, but it is the manner in which Git packages those features that is innovative. Indeed, much of the brilliance of Git is how _simple_ it is conceptually compared to other systems--it is the concepts that Git leaves out, not what it uses, that count.

Moreover, git is extremely fast compared to almost every other VCS. Performance was the thing that pushed Linus to start the project in the first place, but it's still amazing just how fast it is.

Performance was the thing that pushed Linus to start the project in the first place

No, problems with the bitkeeper license was the reason git was started. Linus was very happy with bitkeeper as the VCS for Linux until some kernel contributor tried to reverse engineer parts of bitkeeper which caused the bitkeeper author to threaten to revoke the free license. Git is basically a rewrite of bitkeeper

Sorry, maybe my comment wasn't quite clear enough.

BitKeeper license problems caused him to look for another VCS. However, before he started git, he tried a bunch of other DVCS systems, including open source ones, and decided he couldn't work with them because they were simply too slow. Hence git. See http://en.wikipedia.org/wiki/Git_(software)#Early_history From the quote there it's clear that it's not a BK rewrite. git is apparently faster than BK.

Your post contains several errors and points that I feel need clarifying.

The person in question was Andrew Tridgell, the "reverse engineering" consisted of typing "help" and then observing that the "clone" command would cause BitKeeper to send the entire contents of the repository (see http://lwn.net/Articles/132938/), permitting the extraction of a complete kernel history; and BitMover did not merely threaten to revoke the free license; they actually did.

Finally, Git's data model and internal structure has basically nothing in common with BitKeeper's.

Not sure if anyone clicked through to this, but there is a rather amusing and insightful thread between Linus and Bram Cohen (bittorrent guy) during git's development about some of the crazy ideas and innovations git has. At the time things like diffing at the object level (versus the file level) were considered insane/very hard. These are the types of advances that git made mostly on its own.

http://www.gelato.unsw.edu.au/archives/git/0504/2153.html

(It was two links away from the article. First the 'faster than cp -a' link then, a link on that page.)

As a side note: I'm really surprised to see Bram Cohen in the capacity of naysayer on this!

"I'd like to reiterate that _nothing_ out there supports moving lines between files, and further predict, with total confidence, that if git tries to support such functionality it will simply fail"

Of course, Linus is pushing buttons as always.

My opinion is that the greatest achievement of git is demonstrating that such simple system is perfectly adequate. And git is both conceptually and implementation-wise simpler than anything else out there.

You may have confused BitKeeper with Monotone? The first two of the three concepts you list are in Monotone, and I don't think they are in BitKeeper.

I don't think I am an expert in source control, but here is my source control resume:

* I spent a year (1996-97) where my primary job responsibility was maintaining a homegrown source control system. That was when I started using source control. So I've been using source control software for 13 years.

* Around 1998, I ported patch to native Win32 (although I never released the port, sigh.)

* I've been individually responsible for administering CVS and Subversion servers at two different companies, and part of a team that administered a CVS server at a third.

* I've used CVS, PVCS, Subversion, Git, darcs, Mercurial, and bzr. I wanted to try out ClearCase, Vesta, OpenCM, and Monotone, but I never got around to it.

* One night, I wrote a client to Socialtext's REST API that provides CVS commands and semantics (including conflict detection and automatic merging) for command-line editing of their Wikis. (Available at http://www.canonical.org/~kragen/sw/stclient/ if you like.)

Okay, so now you know I'm really not an expert; I've never even implemented a full source-control system from scratch once. So take my opinion with a grain of salt. Here it is, though:

Git is indeed a fantastic achievement. It is the first source control system that's really designed to be used as a storage platform for applications. It's about 10× faster than other source control systems. (I haven't used Perforce, but I hear it's pretty efficient too.) It provides cryptographically secure authentication of the entire history (an idea taken from Monotone and OpenCM). And the ecosystem of tools around Git is dramatically stronger than the ecosystem around any other source-control system, which is sort of a replication of the major innovation of Linux: decentralized innovation.

GIT is built to manage a large collection of small files. e.g. the linux kernel repos, files that are a only a few KB on average. It is optimized to operate fast on such a cluster of small blobs, but as soon as it processes bigger files (MB,GB) its performance and advantages degrade a lot. Also, the lack of partial checkout makes it painful to get only a subset of the large files that you are storing. Probably because you wouldn't want to checkout only part of the linux kernel.

But those limitations may only be in the Git porcelain, all the plumbing underneath might be a great base for the concept of a distributed file system. GIT is the first step in the right direction, or even could be the platform to support it. http://www.wizbit.org/drupal/ is a company that tries to achieve something like that.

So Git is something that should be built into your OS? Yeah, no shit, that's why Squeak has fine-grained version control built-in, and weren't there operating systems that had version-controlled file-systems?

BeOS, Mac OS X

How does OSX have a versioned file system? I do hope you're not going to say Time Machine, that's a hack. A very clever hack mind you, but it's not a true versioned system, for that we'll have to wait til ZFS.

I hate to say it, but Windows has far better "versioning" than OSX with NTFS's Shadow Copy. Far better filesystem all round actually, which isn't hard. ZFS can't come a moment too soon!

VMS did. It had a configurable (not sure if it was system wide, or user definable) number of versions it kept and it was simple to retrieve past versions (as long as it was within the number of generations it kept). And since it was at the OS level, anywhere you could request a file, you could also specify the version.

I don't know if the versions applied to directories though (I doubt it, but my exposure to VMS was quite brief).

No, just files. And it handled the versioning by copying the whole file, if I recall correctly, at a heinous space cost. (My quota was 500k IIRC.)

Unisys mainframes do (since 1980)! File versions are termed "cycles": by default new files are allocated a single cycle but that can be changed at allocation time or later.

They also had a source editor that kept versions within a file cycle. Lines marked as deleted could be optionally viewed and/or recovered.

Clearcase IS a version controlled file system. It's built around kernel modules. Reiser4 does much the same thing, if I recall correctly.

I am wondering can't we use git as database?

It is a database.

Not a relational database, though. But the Tree objects (1) make a hierarchical database.

(1) http://book.git-scm.com/1_the_git_object_model.html

It will be tough to use as a useful database for most applications without cursors. I'm also not certain that its directories are ordered. If they are, I'm even more doubtful that you can specify a custom ordering.

It's a transcriptional database :)

http://wingolog.org/archives/2008/04/12/git-a-transcriptiona...

Git is an OS now? Let's make a GIT native FS first, or distributed information over 'the cloud'

i'm not sure how any of that makes it the "next unix". a good filesystem replacement/companion maybe, but hardly an operating system.

I just assumed the author decided to say something so ridiculous that nobody would try to question whether it makes sense or not.

It was an analogy, the author was not suggesting git would be an OS.

Unix is much more than an operating system. It's also a time-tested philosophy of building software. See here: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html

Reply on news.ycombinator.com