From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 4FA6C1F428 for ; Thu, 23 Mar 2023 20:44:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231190AbjCWUoi (ORCPT ); Thu, 23 Mar 2023 16:44:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230491AbjCWUog (ORCPT ); Thu, 23 Mar 2023 16:44:36 -0400 Received: from bluemchen.kde.org (bluemchen.kde.org [209.51.188.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 836B212CC4 for ; Thu, 23 Mar 2023 13:44:28 -0700 (PDT) Received: from ugly.fritz.box (localhost [127.0.0.1]) by bluemchen.kde.org (Postfix) with ESMTP id 1E6CC20076 for ; Thu, 23 Mar 2023 16:44:27 -0400 (EDT) Received: by ugly.fritz.box (masqmail 0.3.4, from userid 1000) id 1pfRnO-fER-00 for ; Thu, 23 Mar 2023 21:44:26 +0100 Date: Thu, 23 Mar 2023 21:44:26 +0100 From: Oswald Buddenhagen To: git@vger.kernel.org Subject: Re: limiting git branch --contains Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Mar 23, 2023 at 12:42:52PM -0700, Junio C Hamano wrote: >Oswald Buddenhagen 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?