On Thu, Jan 4, 2024 at 11:33 AM Taylor Blau <me@xxxxxxxxxxxx> wrote: > > [+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...
