Hi Eric,
On Sat, 23 Nov 2019, Eric Wong 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.
The reason I submitted this patch series now is so that we can avoid
inadvertent new users of the `--preserve-merges` backend.
> 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?
Ciao,
Dscho
