Re: js/retire-preserve-merges, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 10, 2021, 05:00 UTC
Message-ID: <xmqqv939uis8.fsf@gitster.g>
In-Reply-To: <nycvar.QRO.7.76.6.2109091307070.59@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 23 quoted lines

> Hi Junio,
>
> On Wed, 8 Sep 2021, Junio C Hamano wrote:
>
>> * js/retire-preserve-merges (2021-09-07) 11 commits
>>  - sequencer: restrict scope of a formerly public function
>>  - rebase: remove a no-longer-used function
>>  - rebase: stop mentioning the -p option in comments
>>  - rebase: remove obsolete code comment
>>  - rebase: drop the internal `rebase--interactive` command
>>  - git-svn: drop support for `--preserve-merges`
>>  - rebase: drop support for `--preserve-merges`
>>  - pull: remove support for `--rebase=preserve`
>>  - tests: stop testing `git rebase --preserve-merges`
>>  - remote: warn about unhandled branch.<name>.rebase values
>>  - t5520: do not use `pull.rebase=preserve`
>>
>>  The "--preserve-merges" option of "git rebase" has been removed.
>>
>>  Will merge to 'next'?
>
> I think so, given the rate of reviews still trickling in tending toward
> zero.

We need to be careful about making our decision on such a trend. For a later iteration, the lack of comments does not give us much information. It can happen if all the comments have adequately been addressed, but it also can happen if none of the suggestions given in earlier rounds are addressed---the reviewers can easily give up and leave.

I think I've followed the topic well enough to tell that it is the former for this instance (i.e. the patches have been polished well enough). Let's merge to 'next' so that we can keep it there long enough.

Thanks.

Show 5 quoted lines

> We probably want to keep it in `next` for quite a while, too, to make sure
> that people get the memo.
>
> Ciao,
> Dscho