8 ms·

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/Artic

• humbledrone 14y ago
  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?
  • Maro 14y ago
    > 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.
    • ggggit 14y ago
      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.
  • kzrdude 14y ago
    a 230MB executable is no fun.. it needs to be read from disk to be executed, and bigger code means worse cache use (for instructions) when running.
    • fusiongyro 14y ago
      It's 115 links to a 2 MB executable. The actual on-disk size is 2 MB.
      • ggggit 14y ago
        Right. I feel stupid that I did not realise this. I am a big fan of crunched binaries, actually. That guy at U of Maryland who introduced it to BSD in the early 90's is a software hero in my book. For Linux fans, I guess your hero would be Bruce Perens or whoever was behind Busybox. Anyway I've learned something more about git from admitting my error. Thank you HN!
        • fusiongyro 14y ago
          You know what's funny? I made the same mistake a year or two ago. :)
• FrankBooth 14y ago
  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 14y ago
    [deleted]
  • vidarh 14y ago
    > 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.
    • ciupicri 14y ago
      Why would/do you run git on a mobile device?
      • ontouchstart 14y ago
        I am running git on a jailbroken 3G iPad 1 during commute. :)
• elij 14y ago
  if you don't need http/https/svn/gtk support then git can be built without perl, curl, git-svn, python etc. installed
  • ggggit 14y ago
    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.
    • vidarh 14y ago
      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.
• wtallis 14y ago
  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.
  • vidarh 14y ago
    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)
    • ggggit 14y ago
      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.
      • vidarh 14y ago
        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)
      • 14y ago
• jey 14y ago
  That's only one implementation of git. There are other implementations that are less kludgey, like libgit2: http://libgit2.github.com/ http://libgit2.github.com/
• vidarh 14y ago
  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.
• ggggit 14y ago
  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
• rmc 14y ago
  You should try using an OS with a proper package manager that can take care of these things.
• Niten 14y ago
  > As for git, it's not nearly as simple as people portray it to be. 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.
  • ggggit 14y ago
    I do understand about the simplicity of the design, though I haven't tried to figure out exactly how git works. 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.
    • Niten 14y ago
      > The real question is what does the function do, and how does it accomplish it? Precisely, and this is where git's simplicity shines compared to other systems. After one takes some time to learn git's data structures, it's trivial to understand exactly what effect each command has on your repository. No need to mentally model your source control system in leaky abstractions, the reality itself is simple enough to handle directly. > 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. Yep, it is true, and that really is all there is to it. For a quick overview, see: http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html http://gitready.com/beginner/2009/02/17/how-git-stores-your-... > I was not aware that there were many implementations of git. I'll now be looking for some other implementations. On github of course. Github itself runs on a proprietary Erlang implementation of Git.