
Git is as revolutionary as Unix pipes (2008) - panarky
http://apenwarr.ca/log/?m=200801#31
======
tzury
This is off topic a bit, but it tells my story about building something on top
of git.

Just several weeks before dropbox came out into light I have completed
building a prototype of what came out to be a dropbox clone on top of git (in
fact, I have had it working with mercurial and bazzar as well, I designed it
to be platform independent) and thought I have in my bare hands a potential
for a great startup (demos were working smoothly, auto syncing files between
clients, web viewer, etc). It was a side project, which I used to work on late
night and weekends, and I gained what I evaluate as great results with no much
effort.

Yet, one morning, I was opening my browser, pointing, as usual, to HN and saw
a post saying dropbox have raised this and that money from Sequoya Capital. I
was eager to know what is this dropbox and what they do and was terribly
shocked to find out they were actually doing the same shit I was in, but, for
longer time, with more and smarter people and fundings.

Soon after, I dropped my project (BTW, it was named StoreAge), and yet could
not use dropbox or hear anything about it for a very long time.

Today I am a happy dropbox user, and git user and waking up every morning
wondering about what will be my next startup.

------
andywhite37
I think Git owes a ton of its success to github.com. Without this extremely
well-designed, central repository for repositories, the uptake of Git would
have been much slower, and faced much more resistance in the wild. Git is a
great tool on its own, but having a centralized place for people to learn and
use Git has been huge.

~~~
j_baker
On the other hand, one could also attribute github's success to git's success.
I suppose it's most likely symbiotic: github contributed to git's success and
vice versa.

~~~
michaelbuckbee
That's undoubtedly true, but I wonder if the GitHub guys had picked up
Mercurial instead if it would have grown as fast.

~~~
lurker19
It git or it github?

------
ggchappell
There are two kinds of articles about DVCSs: (1) git, hg, bzr are all better
than whatever you're using now; (2) git is completely revolutionary, a whole
new paradigm.

This is, of course, the latter sort. I'm wondering why hg, etc. are never
called "a whole new paradigm". I've used all three. Clearly, hg & bzr are
extremely similar, while git works a little differently (the staging area, the
differing semantics of "add", etc.). But I don't see that git has
significantly more awesomeness than the other two.

Am I missing something?

~~~
jmillikin
The second type of article is usually written by converts from legacy VC
systems (cvs/svn) who have never experienced a DVCS before. They attribute the
obvious improvement in usability to Git, never venturing to try anything else;
possibly due to the same fundamental lack of curiosity or self-improvement
that leads to using CVS/SVN at all (post 2005).

What's more, the migration from a single-branch to multiple-branch model is so
empowering that such users tend to view all of Git through rose-tinted glasses
forever after. Compared to that experience, relatively minor usability
improvements like Bazaar's "every working copy has its own tree" or
Mercurial's queues seem insignificant and/or unimportant.

~~~
nupark
_... possibly due to the same fundamental lack of curiosity or self-
improvement that leads to using CVS/SVN at all (post 2005)._

I (and my successful small business) still use SVN, and have done so since
2007. This choice has nothing to do with "fundamental lack of curiosity or
self-improvement." It's a choice born of careful reasoning regarding the
suitability of using DVCS in a centralized organization.

------
sliverstorm
Well, it's been two years and git still isn't making me sandwiches (unlike
Unix pipes), so I think he's been proven wrong.

Honestly, I like git, and I like the 'local copy' model, but I feel people go
a little overboard sometimes with their enthusiasm for git.

~~~
neutronicus
What he's going on about is that git is an efficient implementation of a
purely functional data structure _on disk_. He's advocating using it as one if
you ever need one. This is tangential to its role as a version control system.

~~~
apenwarr
Wow, you just put exactly what I was trying to say into a single simple
sentence. Thanks!

------
erikpukinskis
The vast majority of these comments seem to misunderstand the article as
saying that Git is revolutionary for _managing code_.

That's wrong. The article is about using Git for _managing data_. The examples
cited are using it as a backend for a distributed filesystem or a wiki. The OP
is talking about Git as a revolutionary new kind of datastore and network
protocol, not a revolutionary new kind of VCS.

------
j_baker
I say this as someone who absolutely loves git and thinks it's the best thing
to happen to VCSes in a long time: no it isn't. This kind of advocacy is worse
than useless: when people realize that git isn't a revolutionary concept that
will change computing and is really "just" a VCS (albeit a very good one),
there will be a big backlash.

------
apenwarr
I'm the author of the OP. The comments here make me think (again) that the
article wasn't clear enough: admittedly, when I first wrote it, I was just
discovering git, as some of the comments said. The difference between me and
perhaps many recently-baptized git fanboys is that now, three years later, I
still believe exactly what I wrote. I just now also know why it came across
the wrong way.

Here's what I was trying to get across at the time: git creates a whole new
set of _nouns_ and _verbs_ for computer science that almost none of us have
experienced before. Yes, it steals a lot of concepts from programs like darcs
and monotone, and there are other things that do the same things that git does
from a VCS point of view - but my focus is on the nouns and verbs. git exposes
the plumbing of these new concepts directly to you, which is both scary and
intensely powerful.

git isn't the next Unix because it will replace Unix: git is the next Unix
because its concepts represent the next mind-shifting change in computer
science. I mean that git is the next Unix in the same way you could say "Unix
is the next Lisp" or "Dynamic Languages are the next Static Languages." Not
that the new thing replaces the old thing: they have totally different uses.
But that's the point: the new thing's uses are _really new_. Stuff that was
hard is now easy.

It's hard to imagine the world before Unix pipes (and the Unix sh in general)
were invented, but I used it, and IT SUCKED. The whole Unix paradigm (yikes,
now I've used that word) really changed the face of computing. Even if you
don't use Unix, you got changed by Unix.

git's new nouns are blobs, trees, commits, and refs. The new verbs are push,
pull, merge, tag, etc. You can apply these nouns and verbs to a _lot_ more
than just source code version control.

The naysayers in this thread all sound like 1990's programmers who don't
understand the value of higher-order functions or dynamic typing or macros.
You can survive without those things, but some problems are just _so much
easier_ with them than without them. git is like that. If you don't get it,
you're living in the past.

One final clarification: my article was written to talk about git, but it's
not about git's code or API or repo format at all. bup, the backup software I
started writing about two years after that article, doesn't share any source
code with git, but the amazing things it does are possible because it uses the
new nouns and verbs popularized by git. When new distributed filesystems and
databases and social networks and wikis and massively distributed
collaborative text editors arrive, they will all be using these new nouns and
verbs. If you don't care about that, then yeah, git isn't the next Unix for
you. But if you want to build the next generation of networks in real life,
then you'll either be taking advantage of the new nouns and verbs or you'll be
painstakingly building the Windows of distributed systems.

~~~
haberman
> You can apply these nouns and verbs to a lot more than just source code
> version control.

Do you have any examples of people (other than you) who have actually done
this? It would make your argument much more convincing.

Also, the fact that other DVCS's have different, incompatible models
underlying them suggests that Git's nouns and verbs are not nearly as
universal as Unix pipes. If Git's nouns and verbs were universal, Git could
subsume other DVCS's (ie. you could implement other DVCS's semantics on top of
Git with performance as good or better than what they have already).

~~~
apenwarr
Many of the new "nosql" databases use a lot of similar concepts. But it's a
new thing: I'm trying to see into the future here, not tell you what's already
happened :)

As for different DVCSs, I think you're exactly backwards. Almost everyone
commenting on these things seems to believe that git isn't special, it really
does the same thing as every other DVCS, etc. And on a fundamental level this
is true: it's very easy to convert from one DVCS to another, because
fundamentally the models are so similar. git just exposes the model in a more
obvious way. The _insides_ are the same, the _outsides_ are different.

~~~
eru
The Mercurial guys even go out of their way to show how they are like git
(<http://mercurial.selenic.com/wiki/GitConcepts>).

~~~
levesque
Out of their way? What do you mean? They also have a CvsConcepts page....

~~~
eru
Bad choice of words.

But--try to find a sentence like "Mercurial and Git differ only in
nomenclature and interface." in the CvsConcepts page.

------
Adaptive
And for those that don't realize, the OP author also wrote up git subtree,
which pretty much caused me to take git seriously and change from hg to it.

------
njharman
Binaries work across pipes. With git, not so much.

------
look_lookatme
I remember reading this and being blown away by his enthusiasm.

What are some interesting non-SCM projects that use git? (Like wikis, etc)

~~~
hasenj
github wikis come to mind.

~~~
Whitespace
I've been hacking at gollum (github's FOSS git-based wiki) for some time, and
I might have some interesting uses for it in the education space that go well
past a basic wiki.

~~~
entropie
I'am writing a gollum like wiki atm. Its not finished yet, but works already
and is not far away from a (stable) release: <http://github.com/entropie/oy>

My problem was gollum worked not behind Apache/mod_proxy, so i was forced to
write it on myself ;)

------
patrickg
Has anyone experience with this setup: install your software in a git
repository. That way you can say something like "version=1.23" on top of the
control file (such as a sourcecode file for a scripting language) and the
software system checks out that particular version which is on your hard
drive. There are obvious drawbacks of the system as where to install the
intermediate working directory, but there might be solutions for these
problems.

That way updates may be much less hassle. If you have for example a python
script on your server running doing important things, an update to python
might break the script and could cause some trouble. But if you could say for
example "uses python=x.y" and the system silently falls back to that version
even if a newer version of pyhton is installed, the script is more likely to
keep running even on upgrades.

~~~
neutronicus
<http://nixos.org/nix/>

------
davidu
Whoever this guy is, his blog has been one of my favorites for quite some time
now.

------
happypeter
I love git, and use it to backup my life. Very interesting to know that you
will still be able to checkout what you do today many years later. CVS can do
this as well, it is just not so attractive being much slower.

------
tybris
I used to feel like this way about git. Then I got dropbox and became too lazy
to use git for anything personal.

------
hasenj
I don't remember if I've read this before, but I feel the same way.

The great thing about git is that it's easy to understand. Once you understand
the concepts (and they're really (relatively) simple) and learn the
vocabulary, it gives you tremendous power. At least, it makes you feel that
you have power, hence it empowers you.

> Git is actually the missing link that has prevented me from building the
> things I've wanted to build in the past.

Totally agree with this one.

~~~
mberning
I'm having a hard time understanding the second point. I have never felt that
my VCS prevented me from doing ANYTHING, even when I was forced to use
completely shit systems like Visual Source Safe 6.0.

Are you saying that you wanted to build systems that integrated very tightly
with version control, or that the difficulties you experienced with older
version control tools prevented you from being more adventurous in your
coding?

~~~
hasenj
It's not the presence of a bad VCS. It's the lack of a decent one.

Without git, it's really hard to take bold steps in redesigning the project,
because one would be afraid it won't work, and then you'll lose all the
progress you had so far.

Git solves this problem. Just start a new branch and work in it. If it works,
great, merge mack to the master branch. If it fails, no big deal, discard this
branch and go back to master.

Basically git encourages experimenting in a way no other system does.

~~~
georgieporgie
_Just start a new branch and work in it. If it works, great, merge mack to the
master branch. If it fails, no big deal, discard this branch and go back to
master._

How does that not describe more traditional VCSes like cvs and subversion?

~~~
eru
Merging used to be harder in them, and forking was a big deal.

~~~
aerique
Even moving directories was a pain in the ass in CVS.

