Live data from Hacker News

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

tom.preston-werner.com

11–20 of 22 posts

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

#11
post #10
post #5

This is a wonderful way to teach. Inspired.

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?

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.

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

#12
post #11
post #10

Earlier quoted context omitted.

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?

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.

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.0610191258290.3962@g5.osd...

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

#13

Earlier quoted context omitted.

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,…

You're right. There's remote->fetch, but no pull. Weird. The interface of git seems to assume that you're familiar with the underlying concepts. The official docs and tutorials are pretty good nowadays, but I can see how the interface itself really doesn't give you many clues. (I was already familiar with hg when I started using git, so I picked it up quite quickly.) Coming up with a newbie-friendly interface has pro…

No git pull?

http://www.kernel.org/pub/software/scm/git/docs/git-pull.htm...

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

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

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

#18

Earlier quoted context omitted.

You're right. There's remote->fetch, but no pull. Weird. The interface of git seems to assume that you're familiar with the underlying concepts. The official docs and tutorials are pretty good nowadays, but I can see how the interface itself really doesn't give you many clues. (I was already familiar with hg when I started using git, so I picked it up quite quickly.) Coming up with a newbie-friendly interface has pro…

No git pull? http://www.kernel.org/pub/software/scm/git/docs/git-pull.htm...

He means in the gui. There's a menu item for fetch under remote, but no pull. That seems kind of arbitrary.

(I know about the command.)

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

#19
post #17

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 cer…

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

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

#20
post #19
post #17

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 cer…

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

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.
Post reply on HN