From: Derrick Stolee <derrickstolee@github.com>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>, git@vger.kernel.org
Subject: Re: limiting git branch --contains
Date: Fri, 24 Mar 2023 13:23:32 -0400 [thread overview]
Message-ID: <594a358e-7bd4-e7a1-ad0f-7e41ca1fe767@github.com> (raw)
In-Reply-To: <ZBy6Ku+znv/wuOix@ugly>
On 3/23/2023 4:44 PM, Oswald Buddenhagen wrote:
> On Thu, Mar 23, 2023 at 12:42:52PM -0700, Junio C Hamano wrote:
>> Oswald Buddenhagen <oswald.buddenhagen@gmx.de> 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.
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
next prev parent reply other threads:[~2023-03-24 17:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 18:54 limiting git branch --contains Oswald Buddenhagen
2023-03-23 19:42 ` Junio C Hamano
2023-03-23 20:44 ` Oswald Buddenhagen
2023-03-24 17:23 ` Derrick Stolee [this message]
2023-03-24 18:15 ` Oswald Buddenhagen
2023-03-24 18:20 ` Derrick Stolee
2023-03-24 19:02 ` Oswald Buddenhagen
2023-03-24 19:13 ` Jeff King
2023-03-24 19:58 ` Oswald Buddenhagen
2023-03-24 20:45 ` Jeff King
2023-03-24 22:06 ` Oswald Buddenhagen
2023-03-25 6:30 ` Jeff King
2023-03-25 8:05 ` Oswald Buddenhagen
2023-03-24 19:10 ` Jeff King
2023-03-23 20:56 ` Felipe Contreras
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=594a358e-7bd4-e7a1-ad0f-7e41ca1fe767@github.com \
--to=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=oswald.buddenhagen@gmx.de \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).