Re: Does extending `--empty` to git-cherry-pick make sense?

From: Elijah Newren <newren@gmail.com>
Date: Jan 5, 2024, 02:28 UTC
Message-ID: <CABPp-BGJfvBhO_zEX8nLoa8WNsjmwvtZ2qOjmYm9iPoZg4SwPw@mail.gmail.com>
In-Reply-To: <ZZcIG+mNXhZ0rHw3@nand.local>

On Thu, Jan 4, 2024 at 11:33 AM Taylor Blau <me@ttaylorr.com> wrote:

Show 15 quoted lines

>
> [+cc Elijah]
>
> On Thu, Jan 04, 2024 at 12:57:18AM -0600, Brian Lyles wrote:
> > Is there any real barrier to exposing that option to git-cherry-pick as
> > well? Was this an oversight, or intentionally left out? The
> > corresponding commit message doesn't seem to indicate any specific
> > reason for limiting it to git-rebase.
>
> I am not nearly as familiar with this code as Elijah is, but this
> certainly appears possible by setting the `drop_redundant_commits` and
> `keep_redundant_commits` flags in the replay_opts struct.
>
> I don't see any fundamental reason why cherry-pick shouldn't have the
> same functionality.

I was indeed focused on simply getting the multiple rebase backends to have consistent behavior (we had like 4-5 backends at the time, right?) and just didn't consider cherry-pick at the time. Now that those are more consistent (though there's still work to be done on that end too), cherry-pick and rebase really ought to share a lot more between each other, from command line flags, to temporary control files written, to more shared code paths. Adding an --empty flag to cherry-pick as a step along the way makes sense.

Note that git-am also gained a similar flag in the meantime, but changed the names slightly: --empty=(stop,drop,keep). I think 'stop' is a better name than 'ask', and we really should make rebase suggest 'stop' instead (but keep 'ask' as a synonym for 'stop', for backwards compatibility). Also, I kind of want to replace 'keep' with 'roll' in the --empty option for both git-am and git-rebase, while keeping 'keep' as a synonym for 'roll'. But I'm not sure if others on the list would go along with it...