Re: [PATCH v4 2/3] rebase: stop accepting --rebase-merges=""
- From
Alex Henrie <alexhenrie24@gmail.com>
- Date
- Feb 24, 2023, 17:50 UTC
- Message-ID
- <CAMMLpeQKJeZn4rcTJzFR-ixQXKQMT7t-BKvJqXV4o_4VM=tHYg@mail.gmail.com>
- In-Reply-To
- <xmqqy1on0yla.fsf@gitster.g>
On Fri, Feb 24, 2023 at 10:20 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Wed, 22 Feb 2023, Alex Henrie wrote: > > > >> The unusual syntax --rebase-merges="" (that is, --rebase-merges with an > >> empty string argument) has been an undocumented synonym of > >> --rebase-merges=no-rebase-cousins. Stop accepting that syntax to avoid > >> confusion when a rebase.merges config option is introduced, where > >> rebase.merges="" will be equivalent to not passing --rebase-merges. > > > > Being undocumented and obscure might be a good reason for some to consider > > this a bug; I do not. You could deprecate it, but there are probably > > better ideas than to remove it without prior warning. > > > > If all you want to do is to support `rebase.merges=`, you can do that > > without having to change the meaning of `--rebase-merges=`. > > Thanks for a doze of sanity. Let me mark the topic as on hold to > wait for a resolution.
As Johannes pointed out, it's going to be confusing if rebase.merges="" does not mean rebase.merges=false. It's also going to be confusing if rebase.merges="" does not mean --rebase-merges="". The only sane option I see is to drop --rebase-merges="", or to add a deprecation warning now and drop it later.
-Alex