Re: [PATCH 6/8] git-svn: drop support for `--preserve-merges`
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Nov 24, 2019, 21:29 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1911242224400.31080@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20191123220850.GA29423@dcvr>
Hi Eric,
On Sat, 23 Nov 2019, Eric Wong wrote:
Show 18 quoted lines
> 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.
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