Re: [PATCH] diff: fix behaviour of the "-s" option

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

>  * Then the interaction between "-s" and other format options were
>    poorly implemented.  Modern versions of Git uses one bit each to
>    represent formatting options like "--patch", "--stat" in a single
>    output_format word, but for historical reasons, "-s" also is
>    represented as another bit in the same word.

An obvious improvement strategy is to stop using the NO_OUTPUT bit
and instead make "-s" to clear the "output_format" word, and make
"--[no-]raw", "--[no-]stat", "--[no-]patch", etc. to flip their own
bit in the same "output_format" word.  I think the "historical
reasons" why we did not do that was because we wanted to be able to
do a flexible defaulting.  We may want to say "if no output-format
option is given from the command line, default to "--patch", but
otherwise do not set the "--patch" bit on", for example.
Initializing the "output_format" word with "--patch" bit on would
not work---when "--raw" is given from the command line, we want to
clear that "--patch" bit we set for default and set "--raw" bit on.
We can initialize the "output_format" word to 0, and OR in the bits
for each format option as we process them, and then flip the
"--patch" bit on if "output_format" word is still 0 after command
line parsing is done.  This would almost work, except that it would
make it hard to tell "no command line options" case and "'-s' cleared
all bits" case apart (the former wants to default to "--patch",
while the latter wants to stay "no output"), and it probably was the
reason why we gave an extra NO_OUTPUT bit to the "-s" option.  In
hindsight, the arrangement certainly made other things harder and
prone to unnecessary bugs.

Anyway...