"Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > That commit viewed this, though as > turning that flag into a no-op. Sorry, but I do not understand this sentence. > Provide users a way to drop commits which start empty using a flag that > existed for years: --no-keep-empty. Interpret --keep-empty as > countermanding any previous --no-keep-empty, but otherwise leaving > --keep-empty as the default. But everything after that sentence down to here was very clear. > This might lead to some slight weirdness since commands like > git rebase --empty=drop --keep-empty > git rebase --empty=keep --no-keep-empty > look really weird despite making perfect sense (the first will drop > commits which become empty, but keep commits that started empty; the > second will keep commits which become empty, but drop commits which > started empty). That is true. Do we leave it to others (or our later selves) to think about the UI further? That is fine by me, but in that case we may want to add " We may want to rethink the option names later", perhaps? > +--no-keep-empty:: > --keep-empty:: > + Do not keep commits that start empty before the rebase > + (i.e. that do not change anything from its parent) in the > + result. For commits which become empty after rebasing, see > + the --empty and --keep-cherry-pick flags. keep-cherry-pick will appear later, not here, right? Thanks.
