Re: [RFC PATCH] Option to allow cherry-pick to skip empty commits

[Junio C Hamano <gitster@pobox.com>]

Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:

> This allows cherry-picking a set of commits, some of which may be
> redundant, without stopping to ask for the user intervention.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>  Documentation/git-cherry-pick.txt |  4 ++++
>  builtin/revert.c                  |  1 +
>  sequencer.c                       | 45 +++++++++++++++++++++++++++++++--------
>  sequencer.h                       |  1 +
>  4 files changed, 42 insertions(+), 9 deletions(-)
>
>
> I would like to add to cherry-pick the ability to skip patches. To this
> end, I'm working on two options: a general `--skip-empty` option to
> handle redundant and empty commits by simply skipping them (no user
> intervention), and a `--skip` option as an alternative form to
> `--continue` to skip the ongoing (conflicting or empty) commit.
>
> The patch here presents my implementation of the `--skip-empty` option,
> including documentation. Comments welcome.

Sounds like a useful thing to do.

> +static int allow_or_skip_empty(struct replay_opts *opts, struct commit *commit)
>  {
>  	int index_unchanged, empty_commit;
>  
>  	/*
> -	 * Three cases:
> +	 * Four cases:
>  	 *
> -	 * (1) we do not allow empty at all and error out.
> +	 * (1) we do not allow empty at all and error out;
>  	 *
> -	 * (2) we allow ones that were initially empty, but
> +	 * (2) we skip empty commits altogether;
> +	 *
> +	 * (3) we allow ones that were initially empty, but
>  	 * forbid the ones that become empty;
>  	 *
> -	 * (3) we allow both.
> +	 * (4) we allow both.
>  	 */

The original gave callers the choice to tell two cases (a commit was
empty in the original history, and a commit that was not empty in
the original history turns out to be redundant) apart and handle
them differently.  I tend to agree that skipping the former should
be the norm, and also I think it is sensible to drop the latter, and
that is what your updated (2) gives us, I think.

But I would suspect that it would rather be common to have a
deliberately empty commit in the original as a marker in a history
and want to keep that across cherry-picking a series, while wanting
to discard/skip patches that are already applied in an updated base.
Shouldn't that be supported as the fifth case?