Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 6:21 PM, Jeff King wrote: >> > >> > Is there any reason to use different filenames and sizes for the two >> > runs? They should behave identically, so it would make more sense to me >> > to subject them to identical inputs. >> >> About the sizes, I thought

Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 04:27:10PM +0200, Christian Couder wrote: > >> +while read unpacklimit filesize filename > >> +do > >> [...] > >> +done <<\EOF > >> +1 1024 one-k-file > >> +10 2048 two-k-file > >> +EOF > > > > Is there any reason to use different filenames and sizes for the two > > runs?

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 10:25:44AM +0200, Christian Couder wrote: > >> > Those are patches I plan to share upstream but just haven't gotten > >> > around to yet. > > I would be happy to help if I can on these patches too! Thanks. I'll try to extract the quarantine patches, though I have a few

Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 3:16 PM, Jeff King wrote: > On Tue, Aug 16, 2016 at 10:17:01AM +0200, Christian Couder wrote: >> >> Cleaning up what has already been written to disk is a >> related problem that is not addressed by this patch. >> >> The problem is that git-gc can clean up

Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 10:17:01AM +0200, Christian Couder wrote: > From: Jeff King > > Receive-pack feeds its input to either index-pack or > unpack-objects, which will happily accept as many bytes as > a sender is willing to provide. Let's allow an arbitrary > cutoff point

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 3:03 AM, Jeff King wrote: > On Mon, Aug 15, 2016 at 03:48:55PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > The simple fix is to call register_tempfile() in open_pack_file(), and >> > just have index-pack clean up the file on

[PATCH 3/3] receive-pack: allow a maximum input size to be specified

From: Jeff King Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide. Let's allow an arbitrary cutoff point where we will stop writing bytes to disk. Cleaning up what has already been

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Mon, Aug 15, 2016 at 03:48:55PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The simple fix is to call register_tempfile() in open_pack_file(), and > > just have index-pack clean up the file on its way out. > > > > But there are harder cases. For instance, imagine

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

Jeff King writes: > The simple fix is to call register_tempfile() in open_pack_file(), and > just have index-pack clean up the file on its way out. > > But there are harder cases. For instance, imagine somebody pushes a > 500MB file, and you have a pre-receive hook that says "too

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Mon, Aug 15, 2016 at 09:57:29PM +0200, Christian Couder wrote: > From: Jeff King > > Receive-pack feeds its input to either index-pack or > unpack-objects, which will happily accept as many bytes as > a sender is willing to provide. Let's allow an arbitrary > cutoff point

[RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

From: Jeff King Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide. Let's allow an arbitrary cutoff point where we will stop writing bytes to disk. What has already been written to disk