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

> 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.