Re: [PATCH v2 1/5] Makefile: wire up build option for deprecated features

From: Christian Couder <christian.couder@gmail.com>
Date: Jan 6, 2025, 13:20 UTC
Message-ID: <CAP8UFD3c6Z55m=frXqWS1ffrOK2y-MO8E6vMXsv9q6eWkSYBjA@mail.gmail.com>
In-Reply-To: <CAP8UFD1wM29BFX7ndh905dX8aDF_vdG_azf9phnY+Cgutgfj_Q@mail.gmail.com>

On Mon, Jan 6, 2025 at 12:18 PM Christian Couder <christian.couder@gmail.com> wrote:

Show 19 quoted lines

>
> On Mon, Jan 6, 2025 at 8:51 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > With 57ec9254eb (docs: introduce document to announce breaking changes,
> > 2024-06-14), we have introduced a new document that tracks upcoming
> > breaking changes in the Git project. In 2454970930 (BreakingChanges:
> > early adopter option, 2024-10-11) we have amended the document a bit to
> > mention that any introduced breaking changes must be accompanied by
> > logic that allows us to enable the breaking change at compile-time.
> > While we already have two breaking changes lined up, neither of them has
> > such a switch because they predate those instructions.
> >
> > Introduce the proposed `WITH_BREAKING_CHANGES` preprocessor macro and
> > wire it up with both our Makefiles and Meson.
>
> It's not clear from the above if the two already lined up breaking
> changes are going to use the new build option in this patch, in a
> following patch or in a future patch series after this one. Let's
> see...

It looks like the two already lined up breaking changes are:

  - removing pack-redundant which is handled in patch 4/5, and
  - removing the "branches/" and "remotes/" directories which is
handled in patch 5/5.

Fine, but I think it would be better to be explicit about this.

Thanks.