git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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?

Previous: Giuseppe BilottaNext: Giuseppe Bilotta
Message 2 of 7 in “Option to allow cherry-pick to skip empty commits”
  1. Option to allow cherry-pick to skip empty commitsGiuseppe Bilotta, Jan 21, 2017
  2. Junio C HamanoJan 22, 2017
  3. Giuseppe BilottaJan 23, 2017
  4. Junio C HamanoJan 23, 2017
  5. Giuseppe BilottaJan 23, 2017
  6. Junio C HamanoJan 23, 2017
  7. Giuseppe BilottaJan 23, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.