Initial revision of "git", the information manager from hell
1–10 of 71 posts
Re: Initial revision of "git", the information manager from hell
#2What's most notable about this isn't so much that all the core ideas of git are already in place in the first version. It after all is, fundamentally, a pretty simple piece of software.
What shocks me is that that README was written literally days after the kernel project's license to bitkeeper got revoked.
Re: Initial revision of "git", the information manager from hell
#3Actually this is just the first self-hosted revision of git, but impressively that was apparently only a few days after the actual project start.
Re: Initial revision of "git", the information manager from hell
#4What's most notable about this isn't so much that all the core ideas of git are already in place in the first version. It after all is, fundamentally, a pretty simple piece of software. What shocks me is that that README was written literally days after the kernel project's license to bitkeeper got revoked.
Isn't it funny to think about how, if Tridge hadn't done what he did, if all of Linus' public shaming of Tridge had done the trick and the Linux kernel had stayed on Bitkeeper, that we wouldn't have had git, or Github?
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.
Re: Initial revision of "git", the information manager from hell
#5Tridgwell's "reverse engineering" of BitKeeper is one of the funniest, and at the same time the saddest stories, I've read about software.
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.
Re: Initial revision of "git", the information manager from hell
#6Tridgwell's "reverse engineering" of BitKeeper is one of the funniest, and at the same time the saddest stories, I've read about software. 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 ab…
Uh, is "being easy to statically compile" some benchmark for simplicity that I've never heard of?
Also, what do you care if git is 230MB? Do they even make thumb drives that small any more?
Re: Initial revision of "git", the information manager from hell
#7Tridgwell's "reverse engineering" of BitKeeper is one of the funniest, and at the same time the saddest stories, I've read about software. 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 ab…
svn is quite over-engineered and has significantly more dependencies than git. There's no way a statically linked svn would come out smaller than git, so either you're trolling, lying, or stupid.
Besides, file sizes of statically linked version control binaries is utterly uninteresting for anyone with an ounce of sanity.
Re: Initial revision of "git", the information manager from hell
#8Tridgwell's "reverse engineering" of BitKeeper is one of the funniest, and at the same time the saddest stories, I've read about software. 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 ab…
if you don't need http/https/svn/gtk support then git can be built without perl, curl, git-svn, python etc. installed
Re: Initial revision of "git", the information manager from hell
#9Tridgwell's "reverse engineering" of BitKeeper is one of the funniest, and at the same time the saddest stories, I've read about software. 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 ab…
Uh, is "being easy to statically compile" some benchmark for simplicity that I've never heard of? Also, what do you care if git is 230MB? Do they even make thumb drives that small any more?
> Uh, is "being easy to statically compile" some benchmark for simplicity that I've never heard of?
Yes. It's not the benchmark, but it's a benchmark.
Re: Initial revision of "git", the information manager from hell
#10What's most notable about this isn't so much that all the core ideas of git are already in place in the first version. It after all is, fundamentally, a pretty simple piece of software. What shocks me is that that README was written literally days after the kernel project's license to bitkeeper got revoked.
Isn't it funny to think about how, if Tridge hadn't done what he did, if all of Linus' public shaming of Tridge had done the trick and the Linux kernel had stayed on Bitkeeper, that we wouldn't have had git, or Github? 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.
I'd say we would have had Mercurial, but it was apparently developed for similar reasons:
> 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]