Comparing changes

The documentation for git-rebase(1) indicates that using the `--exec` option will use `--empty=drop`. This is inaccurate: when `--interactive` is not explicitly provided, `--exec` results in `--empty=keep` behaviors. Correctly indicate the behavior of `--exec` using `--empty=keep` when `--interactive` is not specified. Reported-by: Phillip Wood <[email protected]> Signed-off-by: Brian Lyles <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

Both of these pages document very similar `--empty` options, but with different styles. The exact behavior of these `--empty` options differs somewhat, but consistent styling in the docs is still beneficial. This commit aims to make them more consistent. Break the possible values for `--empty` into separate sections for readability. Alphabetical order is chosen for consistency. In a future commit, we'll be documenting a new `--empty` option for git-cherry-pick(1), making the consistency even more relevant. Signed-off-by: Brian Lyles <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

When git-am(1) got its own `--empty` option in 7c096b8 (am: support --empty=<option> to handle empty patches, 2021-12-09), `stop` was used instead of `ask`. `stop` is a more accurate term for describing what really happens, and consistency is good. Update git-rebase(1) to also use `stop`, while keeping `ask` as a deprecated synonym. Update the tests to primarily use `stop`, but also ensure that `ask` is still allowed. In a future commit, we'll be adding a new `--empty` option for git-cherry-pick(1) as well, making the consistency even more relevant. Reported-by: Elijah Newren <[email protected]> Signed-off-by: Brian Lyles <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

When using git-cherry-pick(1) with `--allow-empty` while on an unborn branch, an error is thrown. This is inconsistent with the same cherry-pick when `--allow-empty` is not specified. Detect unborn branches in `is_index_unchanged`. When on an unborn branch, use the `empty_tree` as the tree to compare against. Add a new test to cover this scenario. While modelled off of the existing 'cherry-pick on unborn branch' test, some improvements can be made: - Use `git switch --orphan unborn` instead of `git checkout --orphan unborn` to avoid the need for a separate `rm -rf *` call - Avoid using `--quiet` in the `git diff` call to make debugging easier in the event of a failure. Use simply `--exit-code` instead. Make these improvements to the existing test as well as the new test. Helped-by: Phillip Wood <[email protected]> Helped-by: Junio C Hamano <[email protected]> Signed-off-by: Brian Lyles <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

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 <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

When `--keep-redundant-commits` was added in b27cfb0 (git-cherry-pick: Add keep-redundant-commits option, 2012-04-20), it was not marked as incompatible with the various operations needed to continue or exit a cherry-pick (`--continue`, `--skip`, `--abort`, and `--quit`). Enforce this incompatibility via `verify_opt_compatible` like we do for the other various options. Signed-off-by: Brian Lyles <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

As with git-rebase(1) and git-am(1), git-cherry-pick(1) can result in a commit being made redundant if the content from the picked commit is already present in the target history. However, git-cherry-pick(1) does not have the same options available that git-rebase(1) and git-am(1) have. There are three things that can be done with these redundant commits: drop them, keep them, or have the cherry-pick stop and wait for the user to take an action. git-rebase(1) has the `--empty` option added in commit e98c426 (rebase (interactive-backend): fix handling of commits that become empty, 2020-02-15), which handles all three of these scenarios. Similarly, git-am(1) got its own `--empty` in 7c096b8 (am: support --empty=<option> to handle empty patches, 2021-12-09). git-cherry-pick(1), on the other hand, only supports two of the three possiblities: Keep the redundant commits via `--keep-redundant-commits`, or have the cherry-pick fail by not specifying that option. There is no way to automatically drop redundant commits. In order to bring git-cherry-pick(1) more in-line with git-rebase(1) and git-am(1), this commit adds an `--empty` option to git-cherry-pick(1). It has the same three options (keep, drop, and stop), and largely behaves the same. The notable difference is that for git-cherry-pick(1), the default will be `stop`, which maintains the current behavior when the option is not specified. Like the existing `--keep-redundant-commits`, `--empty=keep` will imply `--allow-empty`. The `--keep-redundant-commits` option will be documented as a deprecated synonym of `--empty=keep`, and will be supported for backwards compatibility for the time being. Signed-off-by: Brian Lyles <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Mar 25, 2024

This comparison is taking too long to generate.