list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Bryan Turner <>
To: Junio C Hamano <>
Cc: Git Users <>,
	Linux Kernel <>,
Subject: Re: [ANNOUNCE] Git v2.22.0-rc1
Date: Mon, 20 May 2019 12:06:07 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

  parent reply	other threads:[~2019-05-20 19:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-19  9:04 Junio C Hamano
2019-05-19 20:30 ` Johannes Schindelin
2019-05-20 19:06 ` Bryan Turner [this message]
2019-05-20 22:27   ` Ævar Arnfjörð Bjarmason
2019-05-21  8:31     ` Duy Nguyen
2019-05-21 10:22       ` Duy Nguyen
2019-05-21 11:24         ` Ævar Arnfjörð Bjarmason
2019-05-21 11:46           ` Duy Nguyen
2019-05-23 15:04 ` New diff test failures on s390x architecture (was: [ANNOUNCE] Git v2.22.0-rc1) Todd Zullinger
2019-05-23 19:14   ` Todd Zullinger
2019-05-23 20:30     ` Duy Nguyen
2019-05-23 21:06       ` Todd Zullinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [ANNOUNCE] Git v2.22.0-rc1' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).