On Thu, Apr 16, 2009 at 11:25:08AM +0200, Johannes Schindelin wrote:
> > This feels very hack-ish to me, but perhaps this is a case of "perfect
> > is the enemy of the good".
>
> I have a strong feeling that none of our diff/rev options can sanely take
> a parameter looking like "--defaults" or "--no-defaults".
>
> But I do not have the time to audit the options. Maybe you have?
Right now, I think we are safe. A few options like "--default" do take a
separated string argument, but saying "--default --no-defaults" seems a
little crazy to me (besides being confusing because they are talking
about two totally unrelated defaults).
Most of the string-taking options require --option=<arg> and don't
support the separated version. If the code were ever parseopt-ified,
they would start to support "--option <arg>"; however, at that time we
should be able to write an "I know about these parseopt options, but
please ignore them according to what we know about them taking an
argument" function.
The one I would worry most about is "-S" since "-S--no-defaults" is a
very reasonable thing to ask for. Right now its argument _must_ be
connected. To be consistent with other git options, "-S --no-defaults"
_should_ be the same thing. But we can perhaps ignore that because:
1. That might never happen, because it breaks historical usage. IOW,
it changes the meaning of "git log -S HEAD" to something else.
2. If it does happen, it is likely to be in a transition to parseopt,
which would fall under the case mentioned above.
I think the biggest danger is that it is a potential bomb for somebody
to add a new revision option which takes an arbitrary string. They
would probably need to keep it as "--option=<arg>" only.
-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