On 3/23/2023 4:44 PM, Oswald Buddenhagen wrote:

On Thu, Mar 23, 2023 at 12:42:52PM -0700, Junio C Hamano wrote:

quoted

Oswald Buddenhagen [off-list ref] writes:

quoted

git branch --contains can be a rather expensive operation in big
repositories. as my use case is actually a rather limited search for
commits in my local wip branches,...

I can do

   $ git branch --list --contains master \??/\*

to show only the topic branches that forked from/after 'master', and
replacing 'master' with v2.40.0 or any older point and the output
starts showing more branches, but the search excludes integration
branches like 'next' and 'seen'.  Is that what you are after?

not really.
the objective is finding the work branch(es) a given sha1 is coming from.
the problem isn't that the above doesn't work, only that it is insanely expensive - on my old machine it takes half a minute in the linux kernel tree.
that's an inevitable effect of trying the branches one after another and not being lucky enough to pick the right branch first. at least that's what appears to be happening.
this could be optimized by doing a piecewise descend on all branches simultaneously (which i presume is what merge-base & co. do), but if the commit actually isn't on any local branch at all, we'd still walk to the very root commit(s) - which is rather wasteful when we actually know that we can cut the walks short.

Could you make sure to run 'git commit-graph write --reachable' before
testing again?

When the commit-graph exists on disk, the algorithm does do a single
reachability walk from all the initial points. If it does not exist,
then each starting point triggers its own reachability walk, which
is significantly slower. See repo_is_descendant_of() in commit-reach.c
for more information on this split.

Thanks,
-Stolee