From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
Nicolas Pitre <nico@cam.org>,
Julian Phillips <julian@quantumfyre.co.uk>,
Daniel Barkalow <barkalow@iabervon.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH] fix simple deepening of a repo
Date: Wed, 26 Aug 2009 10:03:14 -0700 [thread overview]
Message-ID: <20090826170314.GP1033@spearce.org> (raw)
In-Reply-To: <7vk50reykp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >> How will this mesh with 'git clone --mirror'?
> >
> > Not well.
>
> But we at least can assume that the server operator is reasonable and
> wouldn't go overboard, (ab)using this "abbreviated advertisement" feature
> to hide heads and tags from the clients.
Yes. My patch is hardcoded to show only heads and tags, and nothing else.
But I think we want to make this configurable, and show everything
by default, but if there is a configuration entry, show only what
the configuration entry patterns suggest to advertise.
Thus an admin could hide refs/heads/*, but maybe he wants to, and
show only refs/heads/master, refs/heads/maint, refs/heads/next by
default. This is actually a rather clear indication to a client
that although there may be individual cooking topics scattered
through the expanded refs/heads/* space, any reasonable default
clone wouldn't take them.
> Think about in what situation you would want to do a mirror clone.
...
> That means the version of git used to prime, update
> and serve the mirror will know the expand extention.
Great point Junio. The backwards compatibility may be a non-issue
then, especially if this is configurable and we advertise refs/*
by default like we do now, and any reasonable admin who does enable
the hiding still advertises the core namspaces that really matter
to the majority of clients.
> I am hoping that we can finish 1.6.5 by mid September (let's tentatively
> say we will shoot for 16th). I expect the expand extention to be in
> 'next' by that time, cooking for 1.7.0. How does that timetable sound?
Oh, if 1.6.5 is mid-September, this is certainly not 1.6.5 material.
I'm not in any rush, this should go in when its ready, but 1.7
might be reasonable.
--
Shawn.
next prev parent reply other threads:[~2009-08-26 17:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-22 5:52 git fetch --depth=* broken? Nicolas Pitre
2009-08-24 4:04 ` [PATCH] fix simple deepening of a repo Nicolas Pitre
2009-08-24 4:49 ` Junio C Hamano
2009-08-24 13:55 ` Nicolas Pitre
2009-08-24 14:20 ` Johan Herland
2009-08-24 22:21 ` Junio C Hamano
2009-08-24 16:26 ` Daniel Barkalow
2009-08-24 22:30 ` Julian Phillips
2009-08-25 0:18 ` Nicolas Pitre
2009-08-25 2:12 ` Shawn O. Pearce
2009-08-25 5:00 ` Sverre Rabbelier
2009-08-25 5:21 ` Junio C Hamano
2009-08-25 6:12 ` Shawn O. Pearce
2009-08-25 6:33 ` Junio C Hamano
2009-08-25 15:14 ` Shawn O. Pearce
2009-08-26 2:10 ` Shawn O. Pearce
2009-08-26 7:08 ` Johannes Sixt
2009-08-26 8:22 ` Shawn O. Pearce
2009-08-26 9:03 ` Junio C Hamano
2009-08-26 17:03 ` Shawn O. Pearce [this message]
2009-08-28 17:30 ` [RFC PATCH] upload-pack: expand capability advertises additional refs Shawn O. Pearce
2009-08-28 19:07 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090826170314.GP1033@spearce.org \
--to=spearce@spearce.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=julian@quantumfyre.co.uk \
--cc=nico@cam.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.