Re: [RFC] helping smart-http/stateless-rpc fetch race

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> 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@xxxxxxxxx> 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".


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]