Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Derrick Stolee <stolee@gmail.com>,
	 Kristofer Karlsson <krka@spotify.com>
Subject: Re: [PATCH] commit-reach: early exit paint_down_to_common for single merge-base
Date: Mon, 11 May 2026 11:08:26 +0900	[thread overview]
Message-ID: <xmqqh5oevgth.fsf@gitster.g> (raw)
In-Reply-To: <pull.2109.git.1778252837132.gitgitgadget@gmail.com> (Kristofer Karlsson via GitGitGadget's message of "Fri, 08 May 2026 15:07:17 +0000")

"Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> diff --git a/commit-reach.c b/commit-reach.c
> index d3a9b3ed6f..c9d2d594de 100644
> --- a/commit-reach.c
> +++ b/commit-reach.c
> @@ -55,14 +55,16 @@ static int paint_down_to_common(struct repository *r,
>  				struct commit **twos,
>  				timestamp_t min_generation,
>  				int ignore_missing_commits,
> +				int find_all,
>  				struct commit_list **result)
>  {
>  	struct prio_queue queue = { compare_commits_by_gen_then_commit_date };
>  	int i;
> +	int has_gens = min_generation || corrected_commit_dates_enabled(r);

Giving a name that identifies what the commonly-used logical
expression means is a very good idea, but don't some caller pass
min_generation==infinity (i.e., not zero) when there is no
generation available?  E.g., remove_redundant_no_gen() passes
the result of calling commit_graph_generation(), and without commit
graph, we would get infinity here, right?

Given that the second user of this variable is guarded by !find_all,
the variable being true even when we shouldn't be using generation
numbers may not matter for the purpose of the early break, but then
it means that the patch squanders the perfect opportunity to clarify
what the variable means, which is not very lovely.

>  	timestamp_t last_gen = GENERATION_NUMBER_INFINITY;
>  	struct commit_list **tail = result;
>  
> -	if (!min_generation && !corrected_commit_dates_enabled(r))
> +	if (!has_gens)
>  		queue.compare = compare_commits_by_commit_date;
>  
>  	one->object.flags |= PARENT1;
> @@ -97,6 +99,11 @@ static int paint_down_to_common(struct repository *r,
>  			if (!(commit->object.flags & RESULT)) {
>  				commit->object.flags |= RESULT;
>  				tail = commit_list_append(commit, tail);
> +				/* Generation-ordered queue: no later
> +				 * commit can dominate this one. */
> +				if (!find_all && has_gens &&
> +				    generation < GENERATION_NUMBER_INFINITY)
> +					break;

Three comments

 * See Documentation/CodingGuidelines for our preferred style for
   multi-line comments.

 * I do not think we often use "dominate" to describe relationship
   between commits, and I am not sure what you want the word to mean
   in this context.  Can you clarify?

 * The code is getting way too deeply indented.  Perhaps using a
   helper function and


                        if (!(commit->object.flags & RESULT)) {
                                if (mark_result(r, &tail, commit,
						find_all, min_generation))
                                        break;
                        }

   move the logic to mark the newly discovered commit as one of the
   possible result, and to tell the loop to terminate, to it, along
   with the comment on the meaning of its return value, may make the
   code easier to follow?

> +/* To be used only when object flags after this call no longer matter.
> + * When find_all is false and generation numbers are available, returns
> + * after finding the first merge-base, skipping the STALE drain. */

Ditto on the style.

  reply	other threads:[~2026-05-11  2:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 15:07 [PATCH] commit-reach: early exit paint_down_to_common for single merge-base Kristofer Karlsson via GitGitGadget
2026-05-11  2:08 ` Junio C Hamano [this message]
2026-05-11  6:19 ` [PATCH v2] " Kristofer Karlsson via GitGitGadget
2026-05-11  7:22   ` Patrick Steinhardt
2026-05-11 11:22   ` [PATCH v3] " Kristofer Karlsson via GitGitGadget
2026-05-11 12:04     ` Patrick Steinhardt
2026-05-11 12:59     ` [PATCH v4 0/2] [RFC] commit-reach: skip STALE drain when only one merge-base needed Kristofer Karlsson via GitGitGadget
2026-05-11 12:59       ` [PATCH v4 1/2] commit-reach: introduce merge_base_flags enum Kristofer Karlsson via GitGitGadget
2026-05-11 12:59       ` [PATCH v4 2/2] commit-reach: early exit paint_down_to_common for single merge-base Kristofer Karlsson via GitGitGadget
2026-05-12  0:40         ` Junio C Hamano
2026-05-12  5:16           ` Kristofer Karlsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh5oevgth.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=krka@spotify.com \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox