From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, spearce@spearce.org, mfick@codeaurora.org
Subject: Re: [PATCH 0/2] Hiding some refs in ls-remote
Date: Sat, 19 Jan 2013 12:50:10 +0700 [thread overview]
Message-ID: <CACsJy8C4qx0P621imj5B+HdoJkow0_jaGLVDRvdCDw3YRnK98g@mail.gmail.com> (raw)
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
>
> The changes necessary on the client side to allow fetching objects
> at the tip of a ref in hidden hierarchies are much more involved and
> not part of this early preview, but the end user UI is expected to
> be like these:
>
> $ git fetch $there refs/changes/72/41672/1
> $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
>
> That is, you ask for a refname as usual even though it is not part
> of ls-remote response, or you ask for the commit object that is at
> the tip of whatever hidden ref you are interested in.
Should the client side learn how to list hidden refs too? I'm thinking
of an extreme case where upload-pack advertises nothing (or maybe just
refs/heads/master) and it's up to the client to ask for the ref
selection it's interested in. upload-pack may need more updates to do
that, I think.
--
Duy
next prev parent reply other threads:[~2013-01-19 5:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-19 0:37 [PATCH 0/2] Hiding some refs in ls-remote Junio C Hamano
2013-01-19 0:37 ` [PATCH 1/2] upload-pack: share more code Junio C Hamano
2013-01-19 0:37 ` [PATCH 2/2] upload-pack: allow hiding ref hiearchies Junio C Hamano
2013-01-19 5:50 ` Duy Nguyen [this message]
2013-01-19 19:16 ` [PATCH 0/2] Hiding some refs in ls-remote Junio C Hamano
2013-01-20 18:19 ` Junio C Hamano
2013-01-21 1:46 ` Duy Nguyen
2013-01-21 22:56 ` Jeff King
2013-01-19 6:18 ` Michael Haggerty
2013-01-19 16:50 ` Jeff King
2013-01-20 18:06 ` Junio C Hamano
2013-01-20 22:08 ` Junio C Hamano
2013-01-21 23:01 ` Jeff King
2013-01-21 23:33 ` Junio C Hamano
2013-01-21 23:45 ` Jeff King
2013-01-21 23:03 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACsJy8C4qx0P621imj5B+HdoJkow0_jaGLVDRvdCDw3YRnK98g@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mfick@codeaurora.org \
--cc=spearce@spearce.org \
/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.
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 NNTP newsgroup(s).