http://lwn.net/Articles/132938
It's companies like BitKeeper, who think using a command line is "not allowed" that are the reason so much software sucks.
The interface Tridgewell used was the only one I'd be interested in. It's something you could build on top of. You could add abstraction to your heart's content.
As for git, it's not nearly as simple as people portray it to be. You need to have a scripting language (e.g. Perl) and and http client (e.g. curl) already installed or you cannot compile, let alone use git. Now, this is not so bad, if git was just a little glue for some external programs. But try to compile git statically and you will end up with over 230MB of "small, simple, utilities". git is not so simple.
It's command syntax is appealing to many. It makes git seem "simple". But the program itself is not simple in the sense of being robust.
I can complile a static copy of the rcs or cvs programs, or even svn, and take them with me anywhere, all in the space of a few MB's.
git has a lot of dependencies. It's easy to to break.
My half-done AROS port of git (which admittedly does exclude some stuff) currently stands at 1.8MB, with the only external dependency so far being the C library. But the "git" binary has 104 links.
EDIT: Slight correction: There are certainly a number of additional binaries, e.g. for things like "git-instaweb", but the core functionality is held in the main "git" binary.
Also, what do you care if git is 230MB? Do they even make thumb drives that small any more?
Yes. It's not the benchmark, but it's a benchmark.
git's famous simplicity is in the form of its well-designed and stable (and well-documented) underlying data structures, it has nothing to do with the size or runtime dependencies of a particular implementation.
When I see people commenting about git's simplicity it is not about data structures. It is about commands. And that really tells me little about simplicity. Anyone can manipulate the argument structure for a function and positional parameters in a command line interface. The real question is what does the function do, and how does it accomplish it?
The first thing that struck me about git is the apparent use of SHA1 hashing as a basic foundation for the whole system. Maybe that's not even true and no doubt there is much more to it. I'm not out to become an expert in version control nor to understand git completely because I only use it out of necessity. Older systems work just as well for my purposes.
I do not need many advanced features in version control; I'm using version control on a personal basis, not as a contributor to some highly dynamic project with many other contributors. Plain old rcs is still my main tool when I need the ability to move between versions. And diff still seems to work for detecting and printing differences after so many years.
But to me, as a user, the compilation process of any program is also part of any purported "simplicity of design". Programs that compile easily and quickly and are easy to modify score very highly in my book. I am constantly looking for more programs that fit this description.
I was not aware that there were many implementations of git.
I'll now be looking for some other implementations. On github of course.
Total size: 28M
Besides, file sizes of statically linked version control binaries is utterly uninteresting for anyone with an ounce of sanity.
Unless, you, say, want to be able to use it on an embedded device for some reason, or to be able to ship it as part of some project where you have little control over what environment users might want to run it in, say for an IDE running on Android.
Or for ports to far more constrained platforms (e.g. I have a semi-working AROS port. In addition to running on more modern x86, PPC and ARM hardware, AROS can run on original Amiga's, where finding a machine that even has enough memory to load git is a challenge; bizarre edge case? Sure; doesn't mean there aren't plenty of people with edge cases like this)
There are any number of reasons why one would care about size. I wish more developers did - while my mobile devices for example (which do have git) have decent storage space, I've filled most of the 16GB and 32GB respectively of them already, and I'd rather not waste large amounts of space dragging in all kinds of dependencies on stuff that isn't strictly necessary.
That said, in this case, the core functionality of git does in fact not take all that much space.
What shocks me is that that README was written literally days after the kernel project's license to bitkeeper got revoked.
Linus did a good job of coming up with a replacement tool in a hurry, but I'm also grateful to Tridge for poking a stick into the hornets' nest.
> Mackall first announced Mercurial on 19 April 2005. The impetus for this was the announcement earlier that month by Bitmover that they were withdrawing the free version of BitKeeper. [Wikipedia]
One thing that I do remember was just how arrogant Larry McVoy was about whether a replacement SCM could be developed and have feature parity with Bitkeeper. He kept on talking about how he/Bitkeeper is at least a decade ahead of the rest of the community and it would be very difficult to come up with an alternative.
Thankfully, the open source community proved him wrong!
Clickable:
Hmm… I think Linus thought it was stupid.
>+"git" can mean anything, depending on your mood.
Or... He was just in the everything-is-stupid mood.
>+ - random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronounciation of "get" may or may not be relevant.
I think everyone just goes with that. :)
>+ - stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
Here! He said it again!
>+ - "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
GitHub surely took it seriously and made it happen. Thank you!
>+ - "goddamn idiotic truckload of sh*t": when it breaks
Maybe I'll take it. Mainly because I don't want to learn how to think like Linus.
>+This is a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory contents efficiently.
And here's Linus saying git is stupid, again. I think he really means it. Well, at least that day he did.
Anyway, thanks for fossil Dr. Hip! :)
edit: formatting.
See: http://en.wikipedia.org/wiki/Information_hiding
That style is just linus' way. It comes across as a lot more aggressive on screen than in person. To get a better sense of him, I'd recommend watching this talk he gave evangelising git at google back in 2007. It's pretty entertaining, and very educational on the issues facing VCS designers.
http://www.youtube.com/watch?v=4XpnKHJAok8
To a certain extent, if you can knock git together in a couple of weeks you get a free pass to talk however you want, as long as you don't hurt anyone.
I don't mean to start a flamewar on scm, really. But I think git is overly complicated, and I believe I'm not alone on that.
Anyway, don't take things too seriously and have a good one!
PS: You gave a great idea. I should email Linus and offer to pay him some beers. That sure will be a great talk. Thanks mate!
pw = getpwuid(getuid());
if (!pw) usage("You don't exist. Go away!");
