The Git Parable (building a Git-like system from the ground up)

http://tom.preston-werner.com/2009/05/19/the-git-parable.html

by mojombo • 17 years ago

147 20 17 years ago

windsurfer2• 17 years ago

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• 17 years ago

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• 17 years ago

GitX is pretty awesome for Mac. http://gitx.frim.nl/

silentbicycle3• 17 years ago

Could you be more specific?

I'm fine with the command-line interface, but for sake of argument, I'm curious what you think the UI should be like.

windsurfer2• 17 years ago

It would be nice if the interface could walk you through those first few steps you need to take when you're getting introduced to a version control system. Some explanation would be nice. A "Pull" function would also be handy, not to mention some graphics to show where you are in the tree.

The biggest thing that would be needed, however, are some better error messages. Yes, "non fast-forward" is true and descriptive, but a little short for beginners. They are left thinking things like "What is a fast-forward? Why isn't it a fast-forward? Can you just make it work?".

I've looked into changing those error messages (and maybe making the system more internationalized) but they are hard-coded in git's source code, and are not easy to track down.

orestis• 17 years ago

What's wrong with "git gui" and "gitk"? Built in and adequate. Esp. gitk...

cturner• 17 years ago

This is a wonderful way to teach. Inspired.

ajross• 17 years ago

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?

mojombo2• 17 years ago

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.

aupajo• 17 years ago

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.

mr_eel• 17 years ago

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.

jnareb2• 17 years ago

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.

mojombo2• 17 years ago

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

jnareb2• 17 years ago

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.

ttam• 17 years ago

truely awesome article

jhnsntmthy• 17 years ago

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

The Git Parable (building a Git-like system from the ground up)

Related Stories