Junio C Hamano <gitster@xxxxxxxxx> 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...
