git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Tom Saeger <tom.saeger@oracle.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: should git maintenance prefetch be taught to honor remote.fetch refspec?
Date: Fri, 2 Apr 2021 16:43:16 -0400	[thread overview]
Message-ID: <41dc2961-7ba5-a882-3416-45631e2cbb33@gmail.com> (raw)
In-Reply-To: <20210402182716.trbaflsjcvouff2y@brm-x62-17.us.oracle.com>

On 4/2/2021 2:27 PM, Tom Saeger wrote:
> On Thu, Apr 01, 2021 at 06:25:36PM -0400, Derrick Stolee wrote:
>> On 4/1/2021 4:14 PM, Junio C Hamano wrote:
>>> Derrick Stolee <stolee@gmail.com> writes:
>>>
>>>> On 4/1/2021 2:49 PM, Tom Saeger wrote:
>>>
>>> So, redirecting the right-hand of configured refspec is a good idea;
>>> not copying the left-hand of configured refspec, and unconditionally
>>> using "refs/heads/*" is not.
>>  
>> This makes sense as a way to augment the feature. It doesn't seem
>> like a common scenario, but it would be good for users to have
>> that flexibility.
> 
> It's common for me, especially on repos requiring 'maintenance'.

I'm sure that once this is a tool in your belt, then it becomes
common. The number of users who think about refspecs is likely a
small proportion. But features should work as well as they can
for as many users as possible. There's a way forward here, it
just is a little tricky due to the generality of refspecs.

>> Upon initial inspection, it shouldn't be too much work. However,
>> there is some generality to the refspec that might not be wholly
>> appropriate for prefetch (such as the exact_sha1 option). I'm
>> unfamiliar with the advanced forms of the refspec, so it'll take
>> some time to have confidence in this approach.
> 
> Didn't know about exact_sha1.  prefetch probably wouldn't do
> anything in that case?

My guess is that those should be dropped and ignored. But
maybe the approach below will still work?

> 'negative' refspecs - hmm haven't tried those.  I see how that might
> complicate things or maybe not.
> 
> 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/<remote>/*" breaks the refspec.
I think the substring approach will still work here.

> I'm willing to help with/test/review this, thanks for investigating.
I have a branch available [1], but I'm seeing some failures only
on FreeBSD [2] and I can't understand why that platform is failing
this test. The current version (as of this writing) does not do
the substring replacement technique, and hence it just gives up
on exact matches. I will try the substring approach as an
alternative and see where that gets me.

[1] https://github.com/gitgitgadget/git/pull/924
[2] https://github.com/gitgitgadget/git/pull/924/checks?check_run_id=2256079534

Thanks,
-Stolee

  reply	other threads:[~2021-04-02 20:43 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 18:49 should git maintenance prefetch be taught to honor remote.fetch refspec? Tom Saeger
2021-04-01 19:07 ` Derrick Stolee
2021-04-01 19:42   ` Tom Saeger
2021-04-01 20:14   ` Junio C Hamano
2021-04-01 22:11     ` Tom Saeger
2021-04-01 22:25     ` Derrick Stolee
2021-04-02 18:27       ` Tom Saeger
2021-04-02 20:43         ` Derrick Stolee [this message]
2021-04-02 21:07           ` Derrick Stolee
2021-04-02 21:39             ` Tom Saeger
2021-04-02 22:09               ` Junio C Hamano
2021-04-02 22:27                 ` Tom Saeger
2021-04-02 21:15           ` Tom Saeger
2021-04-02 21:19           ` Junio C Hamano
2021-04-02 21:33             ` Tom Saeger
2021-04-04 20:25             ` Derrick Stolee
2021-04-04 23:10               ` Junio C Hamano
2021-04-05 13:20                 ` Derrick Stolee
2021-04-05 18:48                   ` Junio C Hamano
2021-04-05 20:38                     ` Tom Saeger
2021-04-05 20:47                       ` Junio C Hamano
2021-04-05 20:49                         ` Derrick Stolee
2021-04-05 20:50                           ` Tom Saeger
2021-04-05 20:54                             ` Derrick Stolee
2021-04-02 22:32           ` Eric Sunshine
2021-04-03 20:21             ` Tom Saeger
2021-04-03 22:41               ` Derrick Stolee

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=41dc2961-7ba5-a882-3416-45631e2cbb33@gmail.com \
    --to=stolee@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tom.saeger@oracle.com \
    /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).