Re: diff.defaultOptions implementation design [was diff.primer]

From: Keith Cascio <keith@cs.ucla.edu>
Date: Feb 17, 2009, 07:24 UTC
Message-ID: <alpine.GSO.2.00.0902162312030.17111@kiwi.cs.ucla.edu>
In-Reply-To: <20090213222233.GA7424@coredump.intra.peff.net>

Peff,

On Fri, 13 Feb 2009, Jeff King wrote:

Show 6 quoted lines

> So I think doing it right is a bit more work in the long run, but the extra 
> work is generally improving git.
> 
> All that being said, though, I still think we can do the equivalent of 
> --no-primer. The trick to avoiding multiple passes is for the option to exist 
> outside of the set of primer'd options.

I like the idea of using parse-options to handle diff options and I too would like all switches negatable. I will come back to the other ideas you mention if necessary. You laid it all out nicely.

Assuming we can do away with the switches --[no-]default-options, thereby hopefully eliminating the need to accumulate options in any kind of fancy way, certainly the right place to "walk" is in diff_setup(). But diff_setup() must still ascertain at least one runtime fact: whether or not we are running one of the commands that respects default options {diff, log, show}. Is there an elegant way to ascertain that fact from inside diff_setup()? How do you recommend? (BTW I believe my design achieves this elegantly).

                                       -- Keith