git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Tom Saeger <tom.saeger@oracle.com>, git@vger.kernel.org
Subject: Re: should git maintenance prefetch be taught to honor remote.fetch refspec?
Date: Thu, 1 Apr 2021 18:25:36 -0400	[thread overview]
Message-ID: <3bfd9a88-10f9-df71-bf96-f9c5654e48eb@gmail.com> (raw)
In-Reply-To: <xmqq8s613gqa.fsf@gitster.g>

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:
>>> I've recently setup git maintenance and noticed prefetch task
>>> fetches ALL remote refs (well not tags) and does not honor
>>> remote fetch config settings.
>>
>> This is intentional. The point is to get the latest objects
>> without modifying any local copies of refs. You still need
>> to run "git fetch" manually to update the refs, but that
>> should be faster because you have most of the objects already
>> in your copy of the repository.
> 
> You answered only half of the question, I think.

You are right. Thanks, both, for pointing that out.
 
> The plain vanilla refspec after you clone would be
> 
>     [remote "origin"]
> 	fetch = +refs/heads/*:refs/remotes/origin/*
> 
> and "maintenance prefetch" intentionally redirect the destination
> part away from refs/remotes/origin/ to avoid disrupting the
> reference to @{upstream} etc. that are used locally.  And
> intentionally doing so is good.
> 
> But imagine you are tracking my 'todo' branch which has nothing
> common with the history of Git.  You'd have
> 
>     [remote "origin"]
> 	url = git://git.kernel.org/pub/scm/git/git.git
> 	fetch = +refs/heads/todo:refs/remotes/origin/todo
> 
> If "maintenance prefetch" does "+refs/heads/*:refs/prefetch/origin/*",
> you'd end up the history of Git, which is not interesting for you who
> are only interested in the 'todo' branch (to be checked out in the
> Meta subdirectory to use Meta/cook script or read Meta/whats-cooking.txt
> file).
> 
> 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.

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.

Thanks,
-Stolee

  parent reply	other threads:[~2021-04-01 22:25 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 [this message]
2021-04-02 18:27       ` Tom Saeger
2021-04-02 20:43         ` Derrick Stolee
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=3bfd9a88-10f9-df71-bf96-f9c5654e48eb@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).