On Tue, Dec 02, 2014 at 09:45:06AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > For a public repository, it might make sense to provide a config option
> > to loosen the is_our_ref check completely (i.e., to just has_sha1_file).
> > But such an option does not yet exist.
>
> In princi
Jeff King writes:
> For a public repository, it might make sense to provide a config option
> to loosen the is_our_ref check completely (i.e., to just has_sha1_file).
> But such an option does not yet exist.
In principle, yes, but that cannot be has_sha1_file(); it has to
have a fully connected
On Tue, Dec 02, 2014 at 04:47:50PM +1100, Bryan Turner wrote:
> > There is a practical reason to care. Ref deletion will also delete the
> > reflog, leaving no trace of the reachability. Whereas a non-fast-forward
> > push could be resolved by looking in the reflog.
>
> A fair point. I had mistak
On Tue, Dec 2, 2014 at 4:33 PM, Jeff King wrote:
> On Tue, Dec 02, 2014 at 04:04:11PM +1100, Bryan Turner wrote:
>
>> > Can you say more about the context? For example, was this actually
>> > happening, or is this for the sake of understanding the protocol
>> > better?
>>
>> I ask because it's ac
On Tue, Dec 2, 2014 at 12:17 PM, Jonathan Nieder wrote:
>> I'm trying to decide if there is something I can enable or tune to
>> prevent it, and the type of twilighting hinted at by the http-protocol
>> documentation seemed like it could be just the thing.
>
> If you control the side that clones,
On Tue, Dec 02, 2014 at 04:04:11PM +1100, Bryan Turner wrote:
> > Can you say more about the context? For example, was this actually
> > happening, or is this for the sake of understanding the protocol
> > better?
>
> I ask because it's actually happening. Heavy CI load sometimes has
> builds fa
On Tue, Dec 2, 2014 at 12:17 PM, Jonathan Nieder wrote:
> On the server side, I agree that either mining reflogs or storing
> advertisements to disk would be a nice way to take care of this.
> No one has implemented either of those, but it would be a nice setting
> to have. :)
and could be danger
Bryan Turner wrote:
> I ask because it's actually happening. Heavy CI load sometimes has
> builds fail because git clone dies with "not our ref". That's the
> specific context I'm working to try and address right now.
Thanks --- that makes sense.
>
On Tue, Dec 2, 2014 at 3:45 PM, Jonathan Nieder wrote:
> Hi,
>
> Bryan Turner wrote:
>
>> The reason I ask is that there is a race condition that exists where
>> the ref advertisement lists refs/heads/foo at abc1234, and then foo is
>> deleted before the actual upload-pack request comes in.
>
> Ca
Hi,
Bryan Turner wrote:
> The reason I ask is that there is a race condition that exists where
> the ref advertisement lists refs/heads/foo at abc1234, and then foo is
> deleted before the actual upload-pack request comes in.
Can you say more about the context? For example, was this actually
ha
On Tue, Dec 2, 2014 at 3:28 PM, Bryan Turner wrote:
> On Tue, Dec 2, 2014 at 2:34 PM, Jonathan Nieder wrote:
>> Hi Bryan,
>>
>> Bryan Turner wrote:
>>
>>> Is there actually logic somewhere in Git that does that "MAY walk
>>> backwards" step?
>>
>> Yes. See upload-pack.c::check_non_tip and
>> htt
On Tue, Dec 2, 2014 at 2:34 PM, Jonathan Nieder wrote:
> Hi Bryan,
>
> Bryan Turner wrote:
>
>> Is there actually logic somewhere in Git that does that "MAY walk
>> backwards" step?
>
> Yes. See upload-pack.c::check_non_tip and
> http://thread.gmane.org/gmane.comp.version-control.git/178814.
Jon
Hi Bryan,
Bryan Turner wrote:
> Is there actually logic somewhere in Git that does that "MAY walk
> backwards" step?
Yes. See upload-pack.c::check_non_tip and
http://thread.gmane.org/gmane.comp.version-control.git/178814.
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the lin
In Documentation/technical/http-protocol.txt, there is the following statement:
"S: Parse the git-upload-pack request:
Verify all objects in `want` are directly reachable from refs.
The server MAY walk backwards through history or through
the reflog to permit slightly stale requests."
Is there
14 matches
Mail list logo
