On Thu, Mar 23, 2023 at 12:42:52PM -0700, Junio C Hamano wrote:
Oswald Buddenhagen <oswald.buddenhagen@xxxxxx> writes:
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.
am i making sense?
