Phillip Wood <phillip.wood123@xxxxxxxxx> writes: >> This implication of `--allow-empty` therefore seems incorrect: One >> should be able to keep a commit that becomes empty without also being >> forced to pick commits that start as empty. > > Do you have a practical example of where you want to keep the commits > that become empty but not the ones that start empty? I agree there is > a distinction but I think the common case is that the user wants to > keep both types of empty commit or none. I'm not against giving the > user the option to keep one or the other if it is useful but I'm wary > of changing the default. This may not a new issue introduced by this series, but one thing I would be worried about the usability of the keep-redundant is that I know it takes more than one tries of cherry-picking of the same series, at least to me, to get a series right. The initial attempt may make some commit empty and thanks to --keep-redundant they will be kept, but I'll inevitably find more things I need to tweak and cherry-pick the resulting series, possibly on a different base. And to this second round of cherry-pick, these "were not, but now have become empty" commits appear empty from the start.
