ggggit

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.

I am no expert with du and all it's options and behaviours, but it's funny you mention the h, c and s ones because I did bother to learn and commit those three to memory long ago and routinely that combination.

I also use routinely use dd to get "exact" file sizes (yes, it's crude, but dd is on almost every UNIX-like system and it works), unless I have access to a good stat utility.

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!

Maybe he cares first about portability, e.g., easily moving a binary from one BSD-based device to another. Not all devices have the same space limitations.

There might be other reasons, too. Static binaries fork faster, but this works best if they are also small enough to remain entirely in the OS's cache.

There's nothing wrong with dynamic linking per se. Nor is there anything wrong with static linking per se. ("Per se" as used here is intended to mean "in all circumstaces".) The use of one or the other is simply a choice. There are advantages and disadvantages with each method, based on the circumstances and whatever the desired result(s) is/are.

MS: Too big to fail.

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

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.

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.

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.

I would tend to agree with your initial statement.

Which is why I believe what nerds are ranting about on HN does make a difference. I would guess that other users will never find out about certain stuff unless the serious nerds let them- they are the "trend makers" so to speak. Whether popularity equals instant and lasting profit is another question. But no one can deny Twitter has become very popular. It's valuable because it's useful, even if it's not a winner in terms of profitability. (Much like Wikipedia.)

Contrast this with the enormous number of developers who are focused on some mythical end user they can speculate about and that they know they can easily manipulate. Or with folks who are using PR and the tech media to fool investors and generate short-lived buzz amongst less savvy users. Internet VC guilty as charged. These guys are usually rational and know the scent of money a little better. But they cannot control what becomes popular, not like a mob of irrational, fussy nerds can.

Free stuff frustrates a lot of developers. But do not forget the internet is in its infancy. We're still trying to get stuff working. That Twitter even works (the SMS part) is a blessing.

Will App.net be able to make agreements with all the telcos as Twitter did? We shall see.

I doubt they registered in a class covering data processing. How many consumers are going to confuse some data processing service from Google with Dremel tools?

A trademark, unless perhaps it's famous, does not cover everything under the sun, right?

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