linux-kernel - Re: [ANNOUNCE] Git v2.22.0-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 May 2019 12:06:07 -0700
From:   Bryan Turner <bturner@...assian.com>
To:     Junio C Hamano <gitster@...ox.com>
Cc:     Git Users <git@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        git-packagers@...glegroups.com
Subject: Re: [ANNOUNCE] Git v2.22.0-rc1

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

Best regards,
Bryan Turner