From: Junio C Hamano <gitster@pobox.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Sverre Rabbelier <srabbelier@gmail.com>,
Shawn Pearce <spearce@spearce.org>,
git@vger.kernel.org
Subject: Re: [RFC] helping smart-http/stateless-rpc fetch race
Date: Mon, 08 Aug 2011 16:24:43 -0700 [thread overview]
Message-ID: <7vty9rtrk4.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20110808230812.GA16974@LK-Perkele-VI.localdomain> (Ilari Liusvaara's message of "Tue, 9 Aug 2011 02:08:12 +0300")
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> On Mon, Aug 08, 2011 at 11:05:27PM +0200, Sverre Rabbelier wrote:
>> Heya,
>>
>> On Mon, Aug 8, 2011 at 19:13, Junio C Hamano <gitster@pobox.com> wrote:
>> >> (1) It might make sense to give admins who run upload-pack not behind
>> >> smart-http an option to allow fetching from a non-tip; and
>>
>> You said earlier it isn't needed since the server process caches the
>> refs for git and ssh, that leaves dumb-http right?
>
> It seems that everything currently possible falls into three
> categories:
>
> 1) Stateful upload-pack (git://, file://, ssh://, CONNECT): No fix
> needed.
> 2) Stateless upload-pack (smart http://, some bizarre helper):
> Needs fix to avoid races.
> 3) Dumb protocols (dumb http://, ftp://, rsync://): Won't invoke
> upload-pack anyway, no fix needed.
>
> So I think that the only thing that needs the option to allow
> fetching from non-tips is anything using --stateless-rpc.
These (1) and (2) were never meant to be fixes to work around the
smart-http protocol limitation; I know "No fix _needed_" and it was never
a consideration to decide (or choose not to decide) about these two
points.
A separate option would allow admins to let their clients ask to fetch
4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref
if they choose to. That is what (1) is about, and people who do not want
a separate option needs to argue that it is an unnecessary "feature".
next prev parent reply other threads:[~2011-08-08 23:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-05 20:54 [RFC] helping smart-http/stateless-rpc fetch race Junio C Hamano
2011-08-06 21:05 ` Shawn Pearce
2011-08-08 5:03 ` Junio C Hamano
2011-08-08 17:13 ` Junio C Hamano
2011-08-08 21:05 ` Sverre Rabbelier
2011-08-08 23:08 ` Ilari Liusvaara
2011-08-08 23:24 ` Junio C Hamano [this message]
2011-08-08 23:26 ` Junio C Hamano
2011-08-08 23:33 ` Shawn Pearce
2011-08-08 23:42 ` 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=7vty9rtrk4.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
--cc=spearce@spearce.org \
--cc=srabbelier@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.
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).