Re: [RFC PATCH] Option to allow cherry-pick to skip empty commits
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 22, 2017, 23:27 UTC
- Message-ID
- <xmqqpojeu14h.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170121131629.16326-1-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
Show 20 quoted lines
> 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.
Show 20 quoted lines
> +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?