Re: What's cooking in git.git (Jul 2026, #03)

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

Kristofer Karlsson <krka@spotify.com> writes:

> I tried building v6 of kk/merge-base-exhaustion on top of
> kk/commit-reach-find-all-fix but since that one is based
> on kk/paint-down-to-common-optim it does not include
> the changes from kk/commit-reach-optim which I also depend
> on.
>
> I thus think the status of kk/merge-base-exhaustion should
> instead be:
> "On hold, waiting for kk/commit-reach-find-all-fix to land first."
>
> Alternatively you could rebase kk/commit-reach-find-all-fix
> on master (triggers a small conflict though) and that would
> also unblock a reroll (but I don't want to generate more work for you).


When topic A depends on topic B and topic C, rather than rebasing A
on 'next' (if B and C are in 'next'), I would often do

    $ git checkout -b A master
    $ git merge --no-ff B
    $ git merge --no-ff C

these days to prepare the "base" to apply patches that belong to A.

Many contributors mimic this and state in their cover letter that
the patches in the series are to be applied on top of master at
commit X with branches Y and Z merged, or something to that effect.

Thanks.