On Wed, 16 Jul 2008, Avery Pennarun wrote:

quoted text
> 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.

quoted text
> >  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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html