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

From: Elijah Newren <newren@gmail.com>
Date: Mar 31, 2020, 16:27 UTC
Message-ID: <CABPp-BGew8HWChsMVH3ZNS4DuH=nE-GF5ouifP7DhLP-xQ_xbg@mail.gmail.com>
In-Reply-To: <20200330040621.13701-1-jonathantanmy@google.com>

Hi Jonathan,

On Sun, Mar 29, 2020 at 9:06 PM Jonathan Tan <jonathantanmy@google.com> wrote:

Show 10 quoted lines

> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 0c4f038dd6..f4f8afeb9a 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -318,6 +318,21 @@ See also INCOMPATIBLE OPTIONS below.
>  +
>  See also INCOMPATIBLE OPTIONS below.
>
> +--keep-cherry-pick::
> +--no-keep-cherry-pick::

I like the plural form Derrick elsewhere in this thread suggested (--keep-cherry-picks), but it's not a strong preference. However, with fresh eyes I'm slightly worried about "keep". More on that below...

Show 10 quoted lines

> +       Control rebase's behavior towards commits in the working
> +       branch that are already present upstream, i.e. cherry-picks.
> ++
> +By default, these commits will be dropped. Because this necessitates
> +reading all upstream commits, this can be expensive in repos with a
> +large number of upstream commits that need to be read.
> ++
> +If `--keep-cherry-pick is given`, all commits (including these) will be
> +re-applied. This allows rebase to forgo reading all upstream commits,
> +potentially improving performance.

I'm slightly worried that "keep" is setting up an incorrect expectation for users; in most cases, a reapplied cherry-pick will result in the merge machinery applying no new changes (they were already applied) and then rebase's default of dropping commits which become empty will kick in and drop the commit.

Maybe the name is fine and we just need to be more clear in the text on the expected behavior and advantages and disadvantages of this option:

If `--keep-cherry-picks` is given, all commits (including these) will be re-applied. Note that cherry picks are likely to result in no changes when being reapplied and thus are likely to be dropped anyway (assuming the default --empty=drop behavior). The advantage of this option, is it allows rebase to forgo reading all upstream commits, potentially improving performance. The disadvantage of this option is that in some cases, the code has drifted such that reapplying a cherry-pick is not detectable as a no-op, and instead results in conflicts for the user to manually resolve (usually via `git rebase --skip`).

It may also be helpful to prevent users from making a false inference by renaming these options to --[no-]reapply-cherry-pick[s]. Sorry to bring this up so late after earlier saying --[no-]keep-cherry-pick[s] was fine; didn't occur to me then. If you want to keep the name, the extended paragraph should be good enough.

Show 12 quoted lines

> ++
> +See also INCOMPATIBLE OPTIONS below.
> +
>  --rerere-autoupdate::
>  --no-rerere-autoupdate::
>         Allow the rerere mechanism to update the index with the
> @@ -568,6 +583,9 @@ In addition, the following pairs of options are incompatible:
>   * --keep-base and --onto
>   * --keep-base and --root
>
> +Also, the --keep-cherry-pick option requires the use of the merge backend
> +(e.g., through --merge).

Why not just list --keep-cherry-pick[s] in the list of options that require use of the merge backend (i.e. the list containing '--merge') instead of adding another sentence here?

Show 15 quoted lines

> +
>  BEHAVIORAL DIFFERENCES
>  -----------------------
>
> @@ -866,7 +884,8 @@ Only works if the changes (patch IDs based on the diff contents) on
>  'subsystem' did.
>
>  In that case, the fix is easy because 'git rebase' knows to skip
> -changes that are already present in the new upstream.  So if you say
> +changes that are already present in the new upstream (unless
> +`--keep-cherry-pick` is given). So if you say
>  (assuming you're on 'topic')
>  ------------
>      $ git rebase subsystem
> diff --git a/builtin/rebase.c b/builtin/rebase.c

...

Show 5 quoted lines

> @@ -1848,6 +1852,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>                               "interactive or merge options"));
>         }
>
> +       if (options.keep_cherry_pick && !is_interactive(&options))

You're building on an old version of git. Do you want to rebase and make this use the new is_merge() instead so Junio has fewer conflicts to handle?

Show 5 quoted lines

> +               die(_("--keep-cherry-pick does not work with the 'apply' backend"));
> +
>         if (options.signoff) {
>                 if (options.type == REBASE_PRESERVE_MERGES)
>                         die("cannot combine '--signoff' with "

...

Thanks for working on this!