Hi Junio > * bl/cherry-pick-empty (2024-03-11) 7 commits > - cherry-pick: add `--empty` for more robust redundant commit handling > - cherry-pick: enforce `--keep-redundant-commits` incompatibility > - sequencer: do not require `allow_empty` for redundant commit options > - sequencer: treat error reading HEAD as unborn branch > - rebase: update `--empty=ask` to `--empty=stop` > - docs: clean up `--empty` formatting in git-rebase(1) and git-am (1) > - docs: address inaccurate `--empty` default with `--exec` > > "cherry-pick" told to keep redundant commits needs to be allowed to > create empty commits to do its job, but it required the user to > give the --allow-empty option, which was unnecessary. Its UI has > also been tweaked a bit. Note that the description here is a little out-of-date; we're no longer changing the relationship between --allow-empty and --keep-redundant-commits (and the user didn't have to manually supply --allow-empty previously). I'd summarize this as: Allow git-cherry-pick(1) to automatically drop redundant commits via a new `--empty` option, similar to the `--empty` options for git-rebase(1) and git-am(1). Includes a soft deprecation of `--keep-redundant-commits` as well as some related docs changes and sequencer code cleanup. > Comments? > source: <20240119060721.3734775-2-brianmlyles@xxxxxxxxx> You can expect a v4 reroll tonight to address a few remaining comments. The only thing I haven't heard back on is this change [1] to the docs for the new `--empty` option, but I'm confident enough in my proposed alternative there that I'm comfortable rerolling even if I don't hear back today. [1]: https://lore.kernel.org/git/CAHPHrSfiMbU55K2=8+hJZy1cMSRbYM77pCK8BdcAPHLvapHO_A@xxxxxxxxxxxxxx/ -- Thank you, Brian Lyles