Re: ag/rebase-i-rewrite-todo, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2018, 19:40 UTC
Message-ID: <xmqqwou8jgp5.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1807062117170.75@tvgsbejvaqbjf.bet>

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

> Of course, at that point I will have to look through those 7 patches
> again, if only to verify that yes, they are still the same.

That is something the patch author must help the reviewer with, no?

Have uncontroversial stuff early in the series, concentrate on stabilizing them before moving on to shiny new toys, then mark them "unchanged since the last round" after three dashes when sending a reroll to update later parts of the series that are in flux. After a few rounds, it may become apparent to reviewers that these early parts can stand on their own merit as a separate series, on top of which the remaining patches can build as a separate (sub)topic, at which time we may have two or more topics, among which the early one that has become stable may already be 'next'.

> And Alban is not sitting on his hands, either.

If you are saying that all of these 13 are constantly in flux, whether these 13 patches are spread across 3 series or a single one (assuming that all 13 are about the same topic that are interdependant), the need to look at their updated incarnation does not change, so I do not know what you are complaining about.

Show 7 quoted lines

> So after reviewing those 13 patches, which undoubtedly will not be
> integrated into `next` under the premise that they are still in flux, they
> will most likely be joined by another dozen patches until the interactive
> rebase is rewritten completely in C. After which time, I will have
> reviewed the first 3 patches over 15 times.
>
> I wish there was a better way.