Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)

["Brian Lyles" <brianmlyles@gmail.com>]

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@gmail.com>

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@mail.gmail.com/

-- 
Thank you,
Brian Lyles