Re: [PATCH 6/8] git-svn: drop support for `--preserve-merges`

From: Eric Wong <e@80x24.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 6/8] git-svn: drop support for `--preserve-merges`
Date: Mon, 25 Nov 2019 03:15:30 +0000	[thread overview]
Message-ID: <20191125031530.GA29212@dcvr> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1911242224400.31080@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
> > > We already passed the `--rebase-merges` option to `git rebase` instead,
> > > now we make this move permanent.
> >
> > > diff --git a/git-svn.perl b/git-svn.perl
> > > index 4aa208ff5f..f1fa1bc7f7 100755
> > > --- a/git-svn.perl
> > > +++ b/git-svn.perl
> > > @@ -271,7 +271,6 @@ sub _req_svn {
> > >  			  'fetch-all|all' => \$_fetch_all,
> > >  			  'dry-run|n' => \$_dry_run,
> > >  			  'rebase-merges|p' => \$_rebase_merges,
> > > -			  'preserve-merges|p' => \$_rebase_merges,
> > >  			  %fc_opts } ],
> > >  	'commit-diff' => [ \&cmd_commit_diff,
> > >  	                   'Commit a diff between two trees',
> >
> > Nack, it breaks existing usages.   Why the urgency with removal?
> 
> Which urgency? The cover letter spells it out quite clearly that this is
> not even intended for v2.25.0, which is still over 2 months out.

"Months" a blink of an eye when it comes to deprecations and removals.

> The reason I submitted this patch series now is so that we can avoid
> inadvertent new users of the `--preserve-merges` backend.

Then documenting it as deprecated and warning is all that's
needed.

> > I don't know a whole lot about this rebase feature in
> > particular, but deprecation periods should be measured in years
> > or even decades because of LTS distros.  Not months, especially
> > for things which have been around for a long while.
> 
> The LTS distros will not even pick up this patch. So that's a red herring.
> 
> But yes, you're right, v2.25.0 will probably be the first version to even
> have the `--rebase-merges` option in `git svn`, and therefore v2.26.0
> would be awfully early a time to drop `--preserve-merges` in `git svn`.
> Question is whether we want to split this patch series, or just rather
> wait with merging it to `master` until a year from now, or something like
> that?

Fwiw, I object to the regressions to all the other commands
(rebase/pull/remote) in this series, too, but I mainly do Perl.

--preserve-merges was only deprecated in v2.22.0 (2019-06-07).
LTS distro users are very likely on pre-v2.22.0, more likely
v2.1x.0 and maybe even v2.x.0.

Their next LTS release could be several years from now.  We
could be on git 2.[345]x.0 by then and that's when the LTS
packagers could package the next version.  LTS users are likely
to never see the entire period from v2.22.0..v2.25.0 and thus
never see a deprecation warning.

Even Debian stable (not exactly LTS, but still on the slower
side) went from v2.11.0 in Debian 9 all the way to v2.20.1
in Debian 10.  Actual LTS users will see bigger jumps.