Re: Considering teaching plumbing to users harmful

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jul 16, 2008, 21:53 UTC
Message-ID: <alpine.LNX.1.00.0807161605550.19665@iabervon.org>
In-Reply-To: <32541b130807161135h64024151xc60e23d222a3a508@mail.gmail.com>

On Wed, 16 Jul 2008, Avery Pennarun wrote:

Show 9 quoted lines

> On 7/16/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> >  > At the very least, there will be branches.
> >
> > Oh.  And you have to teach plumbing for that?
> 
> In svn, a branch is a revision-controlled directory.  In git, a branch
> is a "ref".  What's a ref?  Well, it's a name for a commit.  What's a
> commit?  Well, it's a blob.  What's a blob?  Err, that's complicated.

You're simply wrong. A ref isn't a name for a commit (the point of having a ref is that it doesn't persist in naming the same commit). A commit isn't a blob. If you start telling people complicated and wrong things, they're surely going to be confused.

Git maintains history as a directed graph, with each commit pointing back at its history. Refs are the what holds the newest commits that nothing else points back to. If directed graphs aren't in your users' experience, you can put it this way: git maintains history like knitting, where each new stitch holds on to one or more previous stitches, and refs are the knitting needles that hold the ends where you're working (except that knitting is a lot wider than software development). gitk --all even provides the diagram you want to explain it.

SVN branches are incredible confusing because they fail to distinguish the directory structure of the project's source tree from the arrangement of available latest versions. And the version numbers for your branch increase when changes are made to other branches.

Show 8 quoted lines

> >  I will not even bother to reply to your mentioning rebase, submodules, and
> >  the "complicated" log due to merges for that very reason: all of this can
> >  be done, easily, with porcelain.
> 
> My point was that the porcelain doesn't even make that stuff easy, and
> thus you need to understand fundamental git internal concepts to use
> them, and fundamental git internals are easiest to teach using the
> plumbing, which doesn't try to hide them.

I don't think the plumbing does a particularly good job of elucidating the fundamental git internals; the plumbing does single operations on the fundamental structures, but that doesn't explain what the fundamental structures are, or what they mean, or why you'd do particular things to them. In fact, they don't at all show the difference between what's expected to change frequently and what's permanent, which will tend to give you wrong ideas.

And for understanding the basic objects, "git show" will work better than "git cat-file" (there's no fundamental reason that trees are binary data and other types aren't, and no particular reason to care about the time format in commit headers, etc), and the plumbing programs for creating the fundamental objects are an even more uneven and arbitrary presentation.

	-Daniel
*This .sig left intentionally blank*