Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > Johannes Schindelin via GitGitGadget <gitgitgadget@xxxxxxxxx> 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.
