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