git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Bryan Turner <bturner@atlassian.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git Users" <git@vger.kernel.org>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>,
	git-packagers@googlegroups.com,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [ANNOUNCE] Git v2.22.0-rc1
Date: Tue, 21 May 2019 00:27:19 +0200	[thread overview]
Message-ID: <87ef4svk1k.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAGyf7-F-d-n39fJmjYc_2rjqQa4d7PFCx63LwW3m7PFetEgzEw@mail.gmail.com>


On Mon, May 20 2019, Bryan Turner wrote:

> 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.

I don't know if argument-less -U was ever intended, but I think in light
of what you're saying we should consider it a regression to fix before
2.22.0 is out. CC-ing Duy who wrote d473e2e0e8 ("diff.c: convert
-U|--unified", 2019-01-27).

The bug there is that the old opt_arg() code would be torelant to empty
values. I noticed a similar change the other day with the --abbrev
option, but didn't think it was worth noting. Maybe it's a more general
problem, in both cases we had a blindspot in our tests.

  reply	other threads:[~2019-05-20 22:27 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
2019-05-20 22:27   ` Ævar Arnfjörð Bjarmason [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=87ef4svk1k.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=bturner@atlassian.com \
    --cc=git-packagers@googlegroups.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --subject='Re: [ANNOUNCE] Git v2.22.0-rc1' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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:

	https://80x24.org/mirrors/git.git

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).