Thread (15 messages) 15 messages, 5 authors, 2026-06-08

Re: limiting git branch --contains

From: Oswald Buddenhagen <hidden>
Date: 2023-03-23 20:44:39

Possibly related (same subject, not in this thread)

On Thu, Mar 23, 2023 at 12:42:52PM -0700, Junio C Hamano wrote:
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.

am i making sense?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help