Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My workplace recently switched to Git and I've been loving (and hating!) it. I really do love it, and it is extremely powerful. The only part I hate is that sometimes it's too powerful (and maybe a bit terse/confusing).

My question is... How was Git designed? Just using it for a short amount of time, you get the feel that it can handle many obscure workflows that other version control systems could not. But it also feels elegant underneath. And fast!

This is no doubt in part to Linus's talent. But I'm wondering, was the overall design of git based off of something? I've read about BitKeeper but the accounts are scant on technical details. The compression, the graphs, getting rid of revision numbers, emphasizing branching, stashing, remotes... Where did it all come from?

Linus really knocked this one out of the park and on pretty much the first try! It's quite good to use once you're past the learning curve.

share|improve this question
    
probably you could get some help on the git IRC channel (#git on freenode) –  yati sagade Nov 11 '11 at 21:35
    
Check out Tech Talk: Linus Torvalds on git –  Asher Nov 11 '11 at 21:40
2  
you get the feel that it can handle many obscure workflows that other version control systems could not: That's probably because it was designed to handle the linux kernel, a notoriously hackish, large and complex piece of code. –  Yannis Rizos Nov 12 '11 at 4:59
add comment

3 Answers

up vote 15 down vote accepted

Git was not designed as much as evolved.

Take a look by yourself. Clone the official git repository, open it in gitk (or your favorite graphical git log viewer), and look at its earliest revisions.

You will see it originally had only the very core functionality (the object database and the index). Everything else was done by hand. However, this small core was designed to be easily automated via shell scripting. The early users of git wrote their own shell scripts to automate common tasks; little by little, these scripts were incorporated into the git distribution (see for an early example 839a7a0). Every time there was a new need, the scripts were adapted to allow for it. Much later, several of these scripts would be rewritten in C.

This combination of a clean, orthogonal core (which you can still use directly if you have the need), with an upper layer which grew organically over it, is what gives git its power. Of course, it is also what gives it the large amount of oddly-named commands and options.


The compression, the graphs, getting rid of revision numbers, emphasizing branching, stashing, remotes... Where did it all come from?

A lot of that was not there in the beginning.

While each object was individually compressed, and duplicates were avoided by their naming, the "pack" files which are responsible for the high compression we are used to seeing in git did not exist. The philosophy in the beginning was "disk space is cheap".

If by "the graphs" you mean graphical viewers like gitk, they appeared later (AFAIK, the first one was gitk). AFAIK, BitKeeper also had a graphical history viewer.

Getting rid of the version numbers, in fact git's core concept of using a content-addressed filesystem to store the objects, mostly came from monotone. At that time, monotone was slow; if this were not the case, it is possible Linus would have used it instead of creating git.

Emphasizing branching is somewhat unavoidable on a distributed version control system, since each clone acts as a separate branch.

Stashing (git stash) is, IIRC, quite recent. The reflogs, which it uses, were not there in the beginning.

Even remotes were not there initially. Originally, you copied the objects by hand using rsync.

One by one, each of these features was added by someone. Not all of them — perhaps not even most of them — were written by Linus. Every time anyone feels a need which git does not fulfill, one can create a new feature over git's core "plumbing" layer, and propose it for inclusion. If it is good, it probably will be accepted, enhancing git's utility (and its command line complexity) even further.

share|improve this answer
    
"AFAIK, BitKeeper also had a graphical history viewer." Yes, it does. It's not exactly pretty, but it's highly functional. See bitkeeper.com/Test.Using.Looking.html, though that does a poor job of showing how it displays branches. –  Bryan Oakley Nov 13 '11 at 17:41
1  
Also an interesting read, a few select emails from the beginning of git, showing a bit of its initial evolution: kerneltrap.org/node/4982 –  CesarB Dec 10 '11 at 15:25
    
Did programmers used to emulate some functionality of git with cvs + rsync + httpd? I'd be interested to hear what homemade solutions were possible. –  Sridhar-Sarnobat Mar 18 at 0:29
add comment

I think the main point is simply that git was designed by the single most qualified person on the planet to do so. And I am not talking about talent, I am talking about experience: I doubt there is anyone else who's been in charge of a codebase with a comparable combination of size and number of contributors as the Linux kernel and still actually dealing with most of the integration work himself.

So Linus knew the requirements and use cases for a distributed version control system better than anyone else. And of course it helped that most of that coding he was dealing was in C, and much of it performance critical.

Basically it's the ultimate example of scratching one's own itch.

share|improve this answer
6  
"Single most qualified"? I don't think so. There are many smart people who are qualified to write distributed source control. The guys at BitMover (the company behind BitKeeper) really really know what they are doing. Linus even gives credit to Larry McVoy for showing him how source code control should work. Without Larry there would be no git. –  Bryan Oakley Nov 12 '11 at 13:07
1  
@BryanOakley, I think we can avoid bashing when someone's complementing someone for something good. High-inside everyone knows that requirement makes a great developer. So, If tomorrow, you are presented with a great problem, we might remember you, as we do Dennis Ritchie. No one's better than the other, it just that they came across a requirement worldwide acknowledged and provided a solution first. –  Pankaj Upadhyay Nov 12 '11 at 13:32
2  
@Bryan: I'm sure the experience in using BitKeeper taught Linus a lot as well, and I should have mentioned that. And sure, there are a lot of other smart, qualified people who know what they're doing. But I still maintain that Linus' experience in maintaining the kernel makes him the most qualified, experience-wise. I may be wrong, but can you point out another project as big, with as many contributors, and where the person responsible for it all is still as deeply involved in getting the actual code of all those contributors to work together? –  Michael Borgwardt Nov 12 '11 at 14:17
    
@Pankaj Upadhyay: I'm not bashing anyone, I was simply explaining why I downvoted the answer. You said something about "provided a solution first" which I think means you think git was somehow "first" in some regard. What do you think it was first at? It certainly wasn't the first distributed scm tool by a long shot. –  Bryan Oakley Nov 12 '11 at 16:44
1  
@DeadMG: The more important part of that statement comes afterwards "...and much of it performance critical". I doubt you'll find many who'll argue that C is not very well suited to implementing low-overhead high-performance code if you know it well. –  Michael Borgwardt Nov 13 '11 at 12:01
show 2 more comments

It was designed pretty much exactly as described in The Git Parable.

Imagine that you have a computer that has nothing on it but a text editor and a few file system commands. Now imagine that you have decided to write a large software program on this system. Because you’re a responsible software developer, you decide that you need to invent some sort of method for keeping track of versions of your software so that you can retrieve code that you previously changed or deleted. What follows is a story about how you might design one such version control system (VCS) and the reasoning behind those design choices.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.