Re: [PATCH v1 1/3] Introduce config variable "diff.primer"

On Sun, Jan 25, 2009 at 06:40:02PM -0800, Keith Cascio wrote:

I agree opt-in is always better with new grammar/semantics.  However,
the constraint I was trying to live inside is: if I call "git diff" on
the command line with no options at all, then primer active.  Yet
perhaps that's not possible, and the only way to do primer is to
require opt-in spelled "--primer".  Then I can tell bash to alias
'gitdiff' as 'git diff --primer' and use that on the command line.

What's the point of aliasing something that isn't "git diff" to "git
diff --primer"? At that point, couldn't you just do away with --primer
entirely and alias "gitdiff" to "git diff --whatever --your --primer
--options --are"?

Anyway, I think that isn't necessary. We _do_ have a mechanism to handle
this already: some commands are plumbing, and must have stable
interfaces, and some commands are porcelain, and can do your magic
automatically. For example, gitk doesn't actually call "git diff"; it
calls "git diff-tree", "git diff-index", etc.

So if you just want this from the command line, then I think it is safe
to have "git diff" always respect "diff.primer", and scripts shouldn't
be impacted.

But this can break down in two ways:

  1. Sometimes we blur the line of plumbing and porcelain, where
     functionality is available only through plumbing. For example,
     gitweb until recently called "git diff" because there is no other
     way to diff two arbitrary blobs. But the solution there is, I
     think, to make that functionality available through plumbing. Not
     to disallow enhancements to porcelain.

  2. When you want a script to take advantage of porcelain-like options,
     the situation is much more difficult (and this is what Junio was
     talking about in his last mail).

     What I think is sane is:

       a. You grow new feature X.
       b. Porcelain takes advantage of any config that asks us to use X.
       c. Plumbing does _not_ respect such config, but will respect
          command line options.
       d. Scripts control which command line options they use; when the
          script writer decides feature X will not interfere (either
          because it is harmless to the script's use, or because the
          script is enhanced to handle the new behavior), then it can
          pass an "--allow-X" command line option.

     And of course that has two disadvantages (and I'm running out of
     numbering schemes):

       I. You have to wait for the script to be updated before you can
          start using X, even if _you_ know that it's harmless.

      II. Point (d) is not always true. Junio mentioned the fact that
          gitk passes command line parameters blindly to rev-list, which
          is potentially unsafe. Up until now, our attitude has been "if
          it hurts, don't do it". In other words, if you call "gitk
          --reverse" and it looks ugly, then it is your fault. :)

-Peff