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

> > 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.

> > 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?