Git development
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Kristofer Karlsson via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Kristofer Karlsson <krka@spotify.com>
Subject: Re: [PATCH v3] commit-reach: early exit paint_down_to_common for single merge-base
Date: Mon, 11 May 2026 14:04:23 +0200	[thread overview]
Message-ID: <agHFxwc_L64hTL7i@pks.im> (raw)
In-Reply-To: <pull.2109.v3.git.1778498532730.gitgitgadget@gmail.com>

On Mon, May 11, 2026 at 11:22:12AM +0000, Kristofer Karlsson via GitGitGadget wrote:
>     Changes since v2 (thanks Patrick for the suggestion):
>     
>      * Replaced the boolean find_all and ignore_missing_commits parameters
>        in paint_down_to_common() with a single enum merge_base_flags
>        mb_flags, reducing the function from 8 to 7 parameters. The enum is
>        defined in commit-reach.h with MERGE_BASE_FIND_ALL and
>        MERGE_BASE_IGNORE_MISSING_COMMITS.
>     
>      * Named the enum merge_base_flags rather than
>        paint_down_to_common_flags since the flags express caller intent and
>        are threaded through multiple layers including the public
>        repo_get_merge_bases_many_dirty() API.
>     
>      * Used mb_flags as the parameter name to avoid shadowing the existing
>        local int flags (commit object flags) inside paint_down_to_common().

Thanks for making these changes. I think it would make sense to split
this up into two commits though, where the first commit only introduces
the new enum (without the new flag) and the second commit then adds the
new flag and the performance optimization.

That'd help quite a bit with the review as it splits up the changes into
a refactoring-only change without any intended semantic change, and
another commit that then does result in a user-visible change.

Patrick

  reply	other threads:[~2026-05-11 12:04 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
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 [this message]
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=agHFxwc_L64hTL7i@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=krka@spotify.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