From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id B8C741F4B4 for ; Fri, 2 Apr 2021 22:09:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231577AbhDBWJH (ORCPT ); Fri, 2 Apr 2021 18:09:07 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:53009 "EHLO pb-smtp2.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229722AbhDBWJG (ORCPT ); Fri, 2 Apr 2021 18:09:06 -0400 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 6C9E6BAA62; Fri, 2 Apr 2021 18:09:03 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=sKYI8TaGK6UkmdRinq2vtlbDwCE=; b=IVNaqD wnJAVDm5KRws00WeWyLlUvraeJFIkksitBJoXiljaduFsHjt04bxd0OyN9XuigX6 Y3VyE8ycF0rrZAxxqPrSCubONyB3ODzlLhK+RPy9IoZuyHS4UtG67F/BkNOBUUvi 3dLEC+AglaPYBRPGuGiT6LpAR0U0Cc77qKVBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=Fq9B11LZUozbq2L0wFrfey6pBYxgWBxH AwAkCXbIkOiKBioXtpU+E97NVdFqIkJr5S5xCfYdfZET95P8DJDiF1xSxBWC3zVv VfIYZ/WO/HwH4uMGy/Ly5JvtCHvZJN7kh+2yMw3Plu1QW4a1n3xzttadUk8RJ6BO JorF1RacDQs= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4F882BAA61; Fri, 2 Apr 2021 18:09:03 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 63917BAA60; Fri, 2 Apr 2021 18:09:02 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Tom Saeger Cc: Derrick Stolee , git@vger.kernel.org Subject: Re: should git maintenance prefetch be taught to honor remote.fetch refspec? References: <20210401184914.qmr7jhjbhp2mt3h6@dhcp-10-154-148-175.vpn.oracle.com> <3bfd9a88-10f9-df71-bf96-f9c5654e48eb@gmail.com> <20210402182716.trbaflsjcvouff2y@brm-x62-17.us.oracle.com> <41dc2961-7ba5-a882-3416-45631e2cbb33@gmail.com> <20210402213909.zuyyqqisvq7gjcxo@brm-x62-17.us.oracle.com> Date: Fri, 02 Apr 2021 15:09:01 -0700 In-Reply-To: <20210402213909.zuyyqqisvq7gjcxo@brm-x62-17.us.oracle.com> (Tom Saeger's message of "Fri, 2 Apr 2021 15:39:09 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 083FE5B0-9400-11EB-B062-74DE23BA3BAF-77302942!pb-smtp2.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Tom Saeger writes: > On Fri, Apr 02, 2021 at 05:07:09PM -0400, Derrick Stolee wrote: >> On 4/2/2021 4:43 PM, Derrick Stolee wrote: >> > On 4/2/2021 2:27 PM, Tom Saeger wrote: >> >> generally isn't it still changing the right-hand side of refspec? >> >> >> >> replacing ":refs/" with ":refs/prefetch/" >> > >> > Right, this substring replacement might be easiest to achieve. The >> > 'struct refspec' doesn't make it incredibly easy. Perhaps skipping >> > the refspec parsing and just doing that substring swap directly from >> > the config value might be the best approach. >> > >> >> This would still work for refspecs with negative patterns right? >> > >> > One of the issues is that negative patterns have no ":refs/" >> > substring. >> > >> > The other issue is that exact matches (no "*") have an exact >> > string in the destination, too, so replacing the _entire_ >> > destination with "refs/prefetch//*" breaks the refspec. >> > I think the substring approach will still work here. >> >> I updated my branch with the substring approach, which is >> probably the better solution. Please give it a try. I don't >> expect that change to help the FreeBSD build, but we will see. > > > This worked for all the scenarios I tried, which had both negatives and > multi remote fetch values. > > Looks good! > > Reviewed-by: Tom Saeger That sounds more like tested-by, but anyway, thanks for working well together. > >> >> > [1] https://github.com/gitgitgadget/git/pull/924 >> > [2] https://github.com/gitgitgadget/git/pull/924/checks?check_run_id=2256079534 >> >> Thanks, >> -Stolee