On Sun, May 19, 2019 at 10:00 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > * The diff machinery, one of the oldest parts of the system, which > long predates the parse-options API, uses fairly long and complex > handcrafted option parser. This is being rewritten to use the > parse-options API. It looks like with these changes it's no longer possible to use "-U" (or, I'd assume, "--unified") without adding an explicit number for context lines. Was it not intended that a user could pass "-U" to explicitly say "I want a unified diff with the default number of context lines"? Because it's always worked that way, as far as I can tell (certainly since early 1.7.x releases). Is it possible, with the new parse-options code, to restore that behavior? Removing that is likely to be a pretty big disruption for Bitbucket Server, which has always explicitly passed "-U" to "git diff". If the community wants to move forward with the change, I understand. I'm not trying to roadblock it; I'm just listing an explicit example of something that will be significantly affected by the change. Perhaps Git 2.22 could emit a warning about the change in behavior and then a subsequent version could turn it into an error, to give us (and anyone else relying on this behavior) more time to make adjustments? I'm aware a unified diff is the default output, but many commands have flags that essentially tell Git to do what it would do by default. That can help counter changes in the default, as well as safeguarding against new config options that allow specifying a different default (as it were). For example, "git diff" has "--no-color", which could override configuration and essentially applied the default behavior--until the default configuration was changed in 1.8.4 from "never" to "auto". By using "--no-color", even though we didn't "need" to, we were protected against that change in the default. Best regards, Bryan Turner
