
The Git Parable (building a Git-like system from the ground up) - mojombo
http://tom.preston-werner.com/2009/05/19/the-git-parable.html
======
jnareb
A few issues where "The Git Parable" diverges from real git history and real
git behavior:

1\. From the beginning it was known that simple numbering system for snapshot
(commit) names would not work without constant access to single central
'numbering authority'. So the history of git is without this meandering; on
the other hand git had example in Monotone, existing distributed version
control system. But this is certainly minor issue.

2\. The staging area was not created to be able to split changes into more
than one commit or keep dirty files in working area (with changes which do not
go into snapshot). This is side benefit, and something you should not abuse.
The main reason behind staging area is _merging_. This is IMHO fairly
important didactic issue.

3\. Git calculates SHA1 of _uncompressed_ object, and then uzes zlib
compression on it, not vice versa as it is said at the end of "The Git
Parable". It used to be the way described (first compress, then SHA1 of
compressed contents) for a very short time and was abandoned; current way
allow to transparently improve compression.

~~~
mojombo
These points are all true, though I'd like to point out that the post is not
intended to be an accurate description of history or implementation. It is
meant as a teaching tool, hence the label "parable."

~~~
jnareb
Even taking into account the fact that its is "parable" and not recount of the
history of Git (which you can find in some detail on Git Wiki, by the way),
one point stays: it is IMVHO bad practice to explain staging area in the terms
of splitting changes into more than one commit and/or comitting with dity
tree, i.e. with some changes uncomitted. Staging area main strength (besides
being explicit version of other SCMs implicit to-be-added area) is dealing
with CONFLICTED MERGE, and that is how it should be explained, I think.

------
cturner
This is a wonderful way to teach. Inspired.

~~~
ajross
I guess. But in this particular case, the early development of git looks
almost _exactly_ like what's described. You can go back and read Linus's early
descriptions and the traffic in the early days on the mailing list and see the
design as it actually unfolded.

Why use a parable when you can use history instead?

~~~
mojombo
It takes a lot more time and effort to sift through mountains of emails than
it does to read a single post whose sole purpose is to distill all that
information into one, easy to consume piece.

~~~
sneakums
Here's a couple of interesting posts Linus wrote a few years ago summarizing
some aspects of Git's history and design.

[http://mid.gmane.org/Pine.LNX.4.64.0605050944200.3622@g5.osd...](http://mid.gmane.org/Pine.LNX.4.64.0605050944200.3622@g5.osdl.org)
[http://mid.gmane.org/Pine.LNX.4.64.0610191258290.3962@g5.osd...](http://mid.gmane.org/Pine.LNX.4.64.0610191258290.3962@g5.osdl.org)

------
mr_eel
This is very nice. It has helped to make the storage mechanism in particular
clearer to me, but also some of the nomenclature used when working with Git —
tree, blob etc.

------
aupajo
Enjoyed reading, followed along for most of it, but as the post wound on it
became increasingly more dense to make sense of.

Some simple pictures or diagrams would make it perfect.

------
windsurfer
Teaching people more than a few commands would be made a lot easier if there
was a proper GUI for git. I find the current GUI to be severely lacking.

~~~
DougBTX
Which gui? TortoiseGit looks like it is making progress:
<http://code.google.com/p/tortoisegit/>

The Porcelain command line interface is quite nice itself. Gitk isn't pretty
(not Apple-style pretty at least) but perfectly functional for viewing logs.

~~~
mcav
GitX is pretty awesome for Mac. <http://gitx.frim.nl/>

------
jhnsntmthy
very awesome, should be a part of the official documentation, because it
provides a great introduction to the concepts, and the thinking behind them

------
ttam
truely awesome article

