Re: Considering teaching plumbing to users harmful

["Avery Pennarun" <apenwarr@gmail.com>]

On 7/16/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>  And with my way of not even bothering to tell users that "git pull" has a
>  default remote and branch, it is easy to tell users about pulling from
>  somewhere else:

I agree that this is the best way to teach git pull.

>  > 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.
What happens when I delete a branch?  Well, it's still in the reflog.
What's the reflog?  Well, it's the local revision history of each
branch.  Local?  Why not shared?  In svn, the revision history of each
branch is shared, but in git, you don't need to, because...

Even git branches are surprisingly concept heavy, unless your users
ask a lot fewer questions than mine.  The really critical question is
why it's so easy to delete a branch in git, and that leads rapidly
into the commit-tree stuff, which is always a spiral into plumbing as
you try to explain the tree of commits.

>  > And so you suddenly need to find out about things like
>  >
>  >        git diff :{1,3}:path/to/filename
>
> No.  Nobody needed that.  All except one user were content with "git
>  diff".  That one wanted "git diff --ours".

I can't find that option in the git-diff man page.

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

>  > Ironically, the plumbing is the only part of git that isn't supposed to
>  > ever change, so it's the most valuable knowledge to have.
>
> Aha.  So we changed porcelain recently, in a backwards-incompatible way?
>  Now, that is news to me.

There are frequent discussions on this list about changing the output
of various porcelains vs. plumbing.  Improving the porcelain output is
useful, because a lot of it right now is mostly accidental (especially
error and progress messages), and to make git easier to use over time,
it will presumably want to be cleaned up.

But if I write a script that uses git and I need to parse the output,
those very useful porcelain changes are backwards incompatible.

The common advice in that case is to only write scripts that use the
plumbing, not the porcelain.  That's fine advice, I think.  But in
svn, I can write scripts using the "svn" command, because its outputs
never change.  Quite unadvanced svn users write shell scripts around
svn, including basic things such as:

   svn status | grep ^C

...to list all conflicted files.  I don't think a similar script
around "git status" is guaranteed not to break.  Perhaps I've
misunderstood though.

Have fun,

Avery