On Thu, Jan 4, 2024 at 11:33 AM Taylor Blau [off-list ref] wrote:

[+cc Elijah]

On Thu, Jan 04, 2024 at 12:57:18AM -0600, Brian Lyles wrote:

quoted

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...