Re: [ANNOUNCE] Git v2.22.0-rc1

> On Sun, May 19, 2019 at 10:00 AM Junio C Hamano <gitster@pobox.com> 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.