Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Initial revision of "git", the information manager from hell

github.com

Post reply on HN
Print view View original

11–20 of 71 posts

Re: Initial revision of "git", the information manager from hell

#11

Post by Maro »

thaumaturgy wrote: post #4
ajross wrote: post #2

What'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 was not familiar with this story and had to look it up. Thanks for the pointer. Seems like the CEO of BitMover shot himself in the leg by being kind of unreasonable and triggering the development of various open source DVCSs, which surely are hurting his bottomline by now.

Clickable:

http://en.wikipedia.org/wiki/BitKeeper

Re: Initial revision of "git", the information manager from hell

#12

Post by wtallis »

ggggit wrote: post #5

Tridgwell'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…

I'd bet that if you built git as a single statically linked multi-call binary a la busybox, it would be far less than 230MB. Statically linking dozens of separate binaries with large amounts of shared code and then measuring the resulting disk usage doesn't tell you anything meaningful except how much disk space dynamic linking would save you.

Re: Initial revision of "git", the information manager from hell

#13

Post by jey »

ggggit wrote: post #5

Tridgwell'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…

That's only one implementation of git. There are other implementations that are less kludgey, like libgit2: http://libgit2.github.com/

Re: Initial revision of "git", the information manager from hell

#14

Post by vidarh »

ggggit wrote: post #5

Tridgwell'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…

You do realize that the git-* binaries by default hardlink to the "git" binary, right? Git is built as a single binary, and uses the program name to pick the right command.

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.

Re: Initial revision of "git", the information manager from hell

#15

Post by vidarh »

wtallis wrote: post #12
ggggit wrote: post #5

Tridgwell'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…

I'd bet that if you built git as a single statically linked multi-call binary a la busybox, it would be far less than 230MB. Statically linking dozens of separate binaries with large amounts of shared code and then measuring the resulting disk usage doesn't tell you anything meaningful except how much disk space dynamic linking would save you.

git is built as a multi-call binary. I wonder if he's perhaps not realizing that all those other "git-*" binaries are hard linked to "git". Depending on which boxes I check on, my git binary has in the region of 80-110 or so hard links (EDIT: admittedly not a statically linked version, but none of it dependencies are big enough that it should add up to anywhere remotely near 230MB)

Re: Initial revision of "git", the information manager from hell

#16

Post by ggggit »

vidarh wrote: post #15
wtallis wrote: post #12

Earlier quoted context omitted.

I'd bet that if you built git as a single statically linked multi-call binary a la busybox, it would be far less than 230MB. Statically linking dozens of separate binaries with large amounts of shared code and then measuring the resulting disk usage doesn't tell you anything meaningful except how much disk space dynamic linking would save you.

git is built as a multi-call binary. I wonder if he's perhaps not realizing that all those other "git-*" binaries are hard linked to "git". Depending on which boxes I check on, my git binary has in the region of 80-110 or so hard links (EDIT: admittedly not a statically linked version, but none of it dependencies are big enough that it should add up to anywhere remotely near 230MB)

So ls -i should show they all share the same inode number?

Thanks for this. I was not aware of that. Perhaps I will give it another try.

Re: Initial revision of "git", the information manager from hell

#17

Post by vog »

thaumaturgy wrote: post #4
ajross wrote: post #2

What'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.

We would still have had Darcs [1]. An without its competitors Git and Mercurial, maybe Darcs would have gotten more enthusiasts pushing Darcs to where Git is today.

[1] http://darcs.net/

Re: Initial revision of "git", the information manager from hell

#18

Post by ggggit »

elij wrote: post #8
ggggit wrote: post #5

Tridgwell'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

Are there instructions anywhere on how to do this? I could have sworn Perl, absent some other scripting language, was an absolute requirement. If it is possible I will have another go.

Re: Initial revision of "git", the information manager from hell

#19

Post by ggggit »

Maro wrote: post #9
humbledrone wrote: post #6

Earlier quoted context omitted.

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.

Thank you Maro. I've never understood why static linking and easy compilation, not to mention being concerned with file sizes, upsets certain people when mentioned on mailing lists and forums. But it always does.

Re: Initial revision of "git", the information manager from hell

#20

Post by [deleted] »

FrankBooth wrote: post #7
ggggit wrote: post #5

Tridgwell'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.

[deleted]
Post reply on HN