Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-11 Thread Jeff King
On Thu, May 11, 2017 at 12:03:54PM -0700, Jonathan Nieder wrote: > > But even leaving all the refs/pull stuff aside, allowAnySHA1InWant does > > seem to increase that confusion, and I don't see a way around it short > > of never sharing objects between repositories at all. So I think at most > >

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-11 Thread Jonathan Nieder
Jeff King wrote: > On Wed, May 10, 2017 at 10:00:44AM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> [1] The reachability checks from upload-pack don't actually do much on >>> GitHub, because you can generally access the objects via the API or >>> the web site anyway. [...] >>

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-11 Thread Jeff King
On Wed, May 10, 2017 at 10:00:44AM -0700, Jonathan Nieder wrote: > > Right, makes sense. I wondered if GitHub should be turning on > > allowTipSHA1InWant, but it really doesn't make sense to. We _do_ hide > > some internal refs[1], and they're things that users wouldn't want to > > fetch. The

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-10 Thread Sebastian Schuberth
On 2017-05-10 19:00, Jonathan Nieder wrote: Right, makes sense. I wondered if GitHub should be turning on allowTipSHA1InWant, but it really doesn't make sense to. We _do_ hide some internal refs[1], and they're things that users wouldn't want to fetch. The problem for your case really is just

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-10 Thread Jonathan Nieder
On Wed, May 10, 2017 at 12:48:37PM -0600, Martin Fick wrote: >> Ævar Arnfjörð Bjarmason wrote: >>> Just a side question, what are the people who use this >>> feature using it for? The only thing I can think of >>> myself is some out of band ref advertisement because >>> you've got squillions of

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-10 Thread Martin Fick
On Wednesday, May 10, 2017 11:20:49 AM Jonathan Nieder wrote: > Hi, > > Ævar Arnfjörð Bjarmason wrote: > > Just a side question, what are the people who use this > > feature using it for? The only thing I can think of > > myself is some out of band ref advertisement because > > you've got

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-10 Thread Jonathan Nieder
Hi, Ævar Arnfjörð Bjarmason wrote: > Just a side question, what are the people who use this feature using > it for? The only thing I can think of myself is some out of band ref > advertisement because you've got squillions of refs as a hack around > git's limitations in that area. That's one

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-10 Thread Ævar Arnfjörð Bjarmason
On Wed, May 10, 2017 at 6:46 AM, Mike Hommey wrote: > On Wed, May 10, 2017 at 12:33:44AM -0400, Jeff King wrote: >> On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: >> >> > > Hmm. That makes sense generally, as the request should succeed. But it >> > > seems like

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-10 Thread Jonathan Nieder
Hi, Jeff King wrote: > Right, makes sense. I wondered if GitHub should be turning on > allowTipSHA1InWant, but it really doesn't make sense to. We _do_ hide > some internal refs[1], and they're things that users wouldn't want to > fetch. The problem for your case really is just on the client

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-09 Thread Mike Hommey
On Wed, May 10, 2017 at 12:33:44AM -0400, Jeff King wrote: > On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > > > > Hmm. That makes sense generally, as the request should succeed. But it > > > seems like we're creating a client that will sometimes succeed and > > > sometimes fail,

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-09 Thread Shawn Pearce
On Tue, May 9, 2017 at 9:33 PM, Jeff King wrote: > On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > >> > Hmm. That makes sense generally, as the request should succeed. But it >> > seems like we're creating a client that will sometimes succeed and >> > sometimes

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-09 Thread Jeff King
On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > > Hmm. That makes sense generally, as the request should succeed. But it > > seems like we're creating a client that will sometimes succeed and > > sometimes fail, and the reasoning will be somewhat opaque to the user. > > I have a

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-09 Thread Shawn Pearce
On Tue, May 9, 2017 at 3:16 PM, Jeff King wrote: > On Tue, May 09, 2017 at 11:20:42AM -0700, Jonathan Tan wrote: > >> fetch-pack, when fetching a literal SHA-1 from a server that is not >> configured with uploadpack.allowtipsha1inwant (or similar), always >> returns an error

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-09 Thread Jeff King
On Tue, May 09, 2017 at 11:20:42AM -0700, Jonathan Tan wrote: > fetch-pack, when fetching a literal SHA-1 from a server that is not > configured with uploadpack.allowtipsha1inwant (or similar), always > returns an error message of the form "Server does not allow request for > unadvertised object

[PATCH] fetch-pack: always allow fetching of literal SHA1s

2017-05-09 Thread Jonathan Tan
fetch-pack, when fetching a literal SHA-1 from a server that is not configured with uploadpack.allowtipsha1inwant (or similar), always returns an error message of the form "Server does not allow request for unadvertised object %s". However, it is sometimes the case that such object is advertised.