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

Johannes Schindelin [off-list ref] wrote:

quoted

Johannes Schindelin via GitGitGadget [off-list ref] wrote:

quoted

We already passed the `--rebase-merges` option to `git rebase` instead,
now we make this move permanent.

quoted

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.

quoted

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.