Re: [PATCH v3] rebase --merge: optionally skip upstreamed commits

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2020, 18:43 UTC
Message-ID: <xmqqd08s74bn.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqh7y474r3.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 5 quoted lines

> True.  So instead of letting the machine match commits on the both
> sides up, the end-user who is rebasing will find matches (or near
> matches) and manually handle them.  It would be a good idea to
> describe the pros and cons for the option (which I think has already
> been written fairly clearly in the proposed patch).

Sorry, strike the part in (parentheses) out. I was looking at the description in an earlier version with --skip-cherry-pick-detection, which had a good explanation on "if such detection is not done, then..." but with the latest one seems to have lost the description altogether. Minimally something like this from the earlier round should probably be resurrected.

    ... these duplicates will be re-applied, which will likely
    result in no new changes (as they are already in upstream) and
    drop them from the resulting history.

Thanks.