All of lore.kernel.org
 help / color / mirror / Atom feed
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".

  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 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.