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

21–30 of 71 posts

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

#21

Post by vidarh »

ggggit wrote: post #16
vidarh wrote: post #15

Earlier quoted context omitted.

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.

For a large chunk of the main binaries. There are certainly some things that are split out in separate binaries and scripts.

On a Debian system, take a look at /usr/lib/git-core/ - it contains a number of additional binaries, but it's still reasonably small. And a lot of what's in there is optional functionality and stuff you can delete if you don't want it. E.g. "git-imap-send", "git-instaweb" and a bunch of other things that you may or may not care about at all.

The main stuff like "git-commit" etc. is all linked to the main binary (or not necessarily present at all, depending on your build/distro).

EDIT: I just compiled a statically linked "git" binary. Stripped it is 2.5MB. That obviously excludes the few things that are in separate binaries. Things like git-daemon weighs in at 1.7MB statically linked.

Some things, like git-imap-send, seems to be a bit tricky to build statically (git-imap-send barfs errors about libdl all over my screen, and I'm not motivated to figure out why)

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

#22

Post by vidarh »

ggggit wrote: post #18
elij wrote: post #8

Earlier quoted context omitted.

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.

From the Makefile (which is exceedingly well commented):

# Define NO_PERL if you do not want Perl scripts or libraries at all. #

I don't know what functionality you lose that way, and you might very well still require it to build it (don't know, not tried), but the core functionality should all work.

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

#23

Post by dspillett »

vog wrote: post #17
thaumaturgy wrote: post #4

Earlier quoted context omitted.

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/

Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?).

Other projects not mature enough yet (and/or moving fast enough in that direction) and he wanted something now?

Or some technical points that he disagreed on, so wrote his own solution that worked the way he preferred instead of trying to change the established workings of other projects?

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

#24

Post by vidarh »

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.

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

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

#25

Post by ggggit »

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…

Edit: As an example, I just compiled subversion 1.6.17. They actually have an --enable-all-static in the configure script which is a nice convenience as libtool can be a real PITA sometimes when trying to link statically.

Total size: 28M

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

#26

Post by mmariani »

>+ GIT - the stupid content tracker

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.

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

#27

Post by masklinn »

dspillett wrote: post #23
vog wrote: post #17

Earlier quoted context omitted.

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/

Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?). Other projects not mature enough yet (and/or moving fast enough in that direction) and he wanted something now ? Or some technical points that he disagreed on, so wrote his own solution that worked the way he preferred instead of trying to change the established workings of other…

> wasn't Mercurial already starting to get somewhere at that time?

Git and Mercurial were started within days of one another, for the same reason (loss of BitKeeper license for the kernel devs).

Mercurial was actually announced 2 week after Git (2005-04-19 vs 2005-04-06)

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

#28

Post by [deleted] »

vog wrote: post #17
thaumaturgy wrote: post #4

Earlier quoted context omitted.

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/

[deleted]

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

#29

Post by regularfry »

dspillett wrote: post #23
vog wrote: post #17

Earlier quoted context omitted.

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/

Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?). Other projects not mature enough yet (and/or moving fast enough in that direction) and he wanted something now ? Or some technical points that he disagreed on, so wrote his own solution that worked the way he preferred instead of trying to change the established workings of other…

At the time darcs had some serious problems - you could quite reliably get into a "merge of death" situation where the tool would just take ages (hours, days) to do a merge on a relatively small codebase. I don't actually know if that played into his thinking or if he just didn't trust a tool written in a language he wasn't as happy hacking in.

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

#30

Post by tytso »

dspillett wrote: post #23
vog wrote: post #17

Earlier quoted context omitted.

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/

Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?). Other projects not mature enough yet (and/or moving fast enough in that direction) and he wanted something now ? Or some technical points that he disagreed on, so wrote his own solution that worked the way he preferred instead of trying to change the established workings of other…

Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?).

Here are Linus's comments about Darcs: http://markmail.org/message/vk3gf7ap5auxcxnb

As far as why not Mercurial, Mercurial was announced on April 19th. Git was announced on April 9th, and was self-hosting on April 7th. There were benchmarks comparing git and Mercurial shortly after Mercurial was announced, and git was faster, although at least originally it used much more disk space (this was before git had implemented compression and pack support).

Post reply on HN