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.
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.
Also, what do you care if git is 230MB? Do they even make thumb drives that small any more?
Yes. It's not the benchmark, but it's a benchmark.
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.
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.
Total size: 28M
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.
What shocks me is that that README was written literally days after the kernel project's license to bitkeeper got revoked.
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.
> 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]
One thing that I do remember was just how arrogant Larry McVoy was about whether a replacement SCM could be developed and have feature parity with Bitkeeper. He kept on talking about how he/Bitkeeper is at least a decade ahead of the rest of the community and it would be very difficult to come up with an alternative.
Thankfully, the open source community proved him wrong!
Clickable:
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.
See: http://en.wikipedia.org/wiki/Information_hiding
That style is just linus' way. It comes across as a lot more aggressive on screen than in person. To get a better sense of him, I'd recommend watching this talk he gave evangelising git at google back in 2007. It's pretty entertaining, and very educational on the issues facing VCS designers.
http://www.youtube.com/watch?v=4XpnKHJAok8
To a certain extent, if you can knock git together in a couple of weeks you get a free pass to talk however you want, as long as you don't hurt anyone.
I don't mean to start a flamewar on scm, really. But I think git is overly complicated, and I believe I'm not alone on that.
Anyway, don't take things too seriously and have a good one!
PS: You gave a great idea. I should email Linus and offer to pay him some beers. That sure will be a great talk. Thanks mate!
pw = getpwuid(getuid());
if (!pw) usage("You don't exist. Go away!");
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-...
> 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.
# 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.
Thanks for this. I was not aware of that. Perhaps I will give it another try.
It would, yes. Another useful tool here is du which by default will screen out files with duplicate inode numbers. So for an example where I have two 100M files each with multiple hard links:
me@swann:/tmp/tmp$ ls -lhi
total 701M
180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link1
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link2
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link3
180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file.link
180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file.link2
me@swann:/tmp/tmp$ du -shc *
101M zero.file
101M zero.file.2
201M total
me@swann:/tmp/tmp$ cd ..
me@swann:/tmp$ du -shc tmp
201M tmp
201M total
Also the number in the 3rd column of the ls output above is the number of links to the object, which can be helpful in understanding this sort of situation too.
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.
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)
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!
http://www.reddit.com/r/programming/comments/9zdlf/git_and_m...
...humble, concerned, and proud of how they've advanced the "state of the art" and his company's contributions to modern version control.
"""Imagine how I'd feel if Linus used BK for years and when moving off he made a centralized VCS."""
I'm better in person; had a meeting with a guy from Germany a couple of years back who worked up the courage to invite himself to our offices in the south bay and after a couple of beers he made some comment like "wow, you're nothing like what I expected, you're actually a nice guy".
I get that a lot. It's a "gift" :)
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.
You might not necessarily supply this solution as part of a product - but if you work somewhere that has a lot of devices to manage, you might want to do this kind of thing yourself, internally. And if you're going to then take it seriously, you'd want to keep previous revisions of all your stuff around, making it easy for you to roll back to previous versions. Files with history, and easy rolling back to previous revisions... git isn't the worst possible way of doing that.
(I've seen this sort of thing done with perforce, pretty much exactly as I describe, to deliver updates of internal tools and manage test builds of products. Daily builds of tools and products get checked in to perforce each day; most days, QA test that day's build results; if a a given day's build proves not to be a big pile of crap, they tag the corresponding revision. Then you can use perforce to find half-decent historical builds, and retrieve them. The place I saw this done at had a little tool that somebody had written to put a friendly GUI face on this process.)
The only problem is that it had a feeling of non-robustness when using it, and because of that I was tempted to have multiple copies of my repos, just in case of corruption. And that kinda defeats the purpose of VCS.
Then, git came along. Although a bit strange in the beginning, especially on windows, it felt robust enough from the start. And it supported multiple workflows. I know that, whatever stupid thing I do in my repo, git will never loose any data, and I'll be able to google an answer how to recover from my mistakes.
That being said, I'm glad darcs is still alive and kicking. Guys behind it are really smart, and who knows what new good ideas can come from it.
You are forgetting Tom Lord's arch, which had a really bizarre interface (even more so than Darcs), but was conceptually very nice.
Darcs has a terrific consistent interface. Git has taken liberally from it. "git log -p" and "git add -p" are straight from darcs. AFAIK, nothing before darcs could look at a repo as a stream of diffs and comments.
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?
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).
I think you might be thinking of Monotone here. Mercurial was started some days after git.
EDIT: Wikipedia has some info about what Linus thought of Monotone. The key problem with it was performance. I have no idea to what degree they have been fixed today.
https://en.wikipedia.org/wiki/Monotone_%28software%29#Monoto...
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)
From what I can tell maybe age and experience have mellowed you out your email tone a bit... pretty soon you'll turn into Ned from The Simpsons. ;-)
I've been too disgusted with the result to actually fix it but it clearly needs some lovin. I don't suppose anybody wants to tackle marketing BitKeeper? Not a fun job given that we annoyed the open source crowd but we do have some neat technology.
Github is in a different space, we don't see them much. We do see git of course, but lucky for us some of the design decisions in git left us some advantages (see the facebook thread about 6 months ago).
I dunno about Ned, isn't he the religious guy? I'm more the grumpy old man :)