]> git.ipfire.org Git - thirdparty/git.git/commit
sequencer: do not require `allow_empty` for redundant commit options
authorBrian Lyles <brianmlyles@gmail.com>
Mon, 25 Mar 2024 23:16:52 +0000 (18:16 -0500)
committerJunio C Hamano <gitster@pobox.com>
Mon, 25 Mar 2024 23:45:40 +0000 (16:45 -0700)
commit661b671aec3683718fe58f78f85359a11f57a57a
tree1eae84c736a84c64fe68e3330c6b6e5667e2a3a8
parent1b90588d620a2970c82025c272e14f32d5e5969d
sequencer: do not require `allow_empty` for redundant commit options

A consumer of the sequencer that wishes to take advantage of either the
`keep_redundant_commits` or `drop_redundant_commits` feature must also
specify `allow_empty`. However, these refer to two distinct types of
empty commits:

- `allow_empty` refers specifically to commits which start empty
- `keep_redundant_commits` refers specifically to commits that do not
  start empty, but become empty due to the content already existing in
  the target history

Conceptually, there is no reason that the behavior for handling one of
these should be entangled with the other. It is particularly unintuitive
to require `allow_empty` in order for `drop_redundant_commits` to have
an effect: in order to prevent redundant commits automatically,
initially-empty commits would need to be kept automatically as well.

Instead, rewrite the `allow_empty()` logic to remove the over-arching
requirement that `allow_empty` be specified in order to reach any of the
keep/drop behaviors. Only if the commit was originally empty will
`allow_empty` have an effect.

Note that no behavioral changes should result from this commit -- it
merely sets the stage for future commits. In one such future commit, an
`--empty` option will be added to git-cherry-pick(1), meaning that
`drop_redundant_commits` will be used by that command.

Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sequencer.c