Junio C Hamano wrote: > 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. That's easy to solve by introducing a DIFF_FORMAT_DEFAULT item, which would be different from 0. Then every command can update DIFF_FORMAT_DEFAULT to the desired default, and if the default is cleared (e.g. `--no-patch`) that would not happen. -- Felipe Contreras
