Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
- From
Brian Lyles <brianmlyles@gmail.com>
- Date
- Mar 20, 2024, 15:15 UTC
- Message-ID
- <17be81eb83ff314d.70b1dd9aae081c6e.203dcd72f6563036@zivdesk>
- In-Reply-To
- <xmqqil1iqi37.fsf@gitster.g>
Hi Junio
Show 13 quoted lines
> * 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