From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: Bryan Turner <firstname.lastname@example.org> Cc: "Junio C Hamano" <email@example.com>, "Git Users" <firstname.lastname@example.org>, "Linux Kernel" <email@example.com>, firstname.lastname@example.org, "Nguyễn Thái Ngọc Duy" <email@example.com> Subject: Re: [ANNOUNCE] Git v2.22.0-rc1 Date: Tue, 21 May 2019 00:27:19 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (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 <email@example.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.
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).