From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, jrnieder@gmail.com,
Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] fetch: add --no-update-remote-refs
Date: Fri, 17 Jan 2020 14:26:10 -0500 [thread overview]
Message-ID: <20200117192610.GC11358@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqa76lew1l.fsf@gitster-ct.c.googlers.com>
On Fri, Jan 17, 2020 at 11:13:10AM -0800, Junio C Hamano wrote:
> > Add a --[no-]update-remote-refs option to 'git fetch' which defaults
> > to the existing behavior of updating the remote refs. This allows
> > a user to run
> >
> > git fetch <remote> --no-update-remote-refs +refs/heads/*:refs/hidden/*
> >
> > to populate a custom ref space and download a pack of the new
> > reachable objects.
>
> Hmph. I have to wonder if this should have been the default. That
> is, when refs/heads/X on the remote is configured to be copied to
> refs/remotes/origin/X on this side, and an explicit refspec says it
> should go some other place (i.e. refs/hidden/X), shouldn't that
> automatically bypass configured +refs/heads/*:refs/remotes/origin/*
> refspec? In any case, it is too late to change that now.
It used to be the default. You can blame 2013-me. ;)
Before that, though, we had people complaining the other way ("I just
fetched from the remote, but my tracking ref is stale!").
> > 3. With fetch.writeCommitGraph enabled, the refs/hidden refs are
> > used to update the commit-graph file.
>
> I have a moderately strong suspicion that it would be better to make
> this "--ignore-configured-refspecs" and implemented without special
> casign the "refs/remotes/" hierarchy like the code does by
> hardcoding.
Yeah, I just independently wrote something similar. Your "--refmap"
option can accomplish that already.
> I also wonder if auto-following of tags should be disabled at the
> same time. I have no good argument either way (yet).
I _didn't_ think of tag auto-following in my other response. That's a
good point. I think he'd probably just want to use "--no-tags" for the
background fetch. You'd end up having to fetch the tag objects
themselves during the "real" fetch, but presumably they're very small
compared to the rest of history.
You could also do:
git fetch --refmap= <remote> +refs/heads/*:refs/hidden/heads/* +refs/tags/*:refs/hidden/tags/*
to get everything in your pre-fetch (though you actually get more than
the real fetch would need, since by default it won't grab tags which
don't point to otherwise-reachable history).
-Peff
next prev parent reply other threads:[~2020-01-17 19:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-17 15:28 [PATCH] fetch: add --no-update-remote-refs Derrick Stolee via GitGitGadget
2020-01-17 16:23 ` Eric Sunshine
2020-01-17 19:13 ` Junio C Hamano
2020-01-17 19:26 ` Jeff King [this message]
2020-01-20 14:44 ` Derrick Stolee
2020-01-17 19:20 ` Jeff King
2020-01-21 0:57 ` Derrick Stolee
2020-01-21 1:38 ` [PATCH v2] fetch: document and test --refmap="" Derrick Stolee via GitGitGadget
2020-01-21 16:24 ` Jeff King
2020-01-21 18:01 ` Derrick Stolee
2020-01-21 19:06 ` Jeff King
2020-01-21 18:22 ` Junio C Hamano
2020-01-21 18:24 ` Junio C Hamano
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=20200117192610.GC11358@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.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).