Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified
- From
Jeff King <peff@peff.net>
- Date
- Aug 16, 2016, 01:03 UTC
- Message-ID
- <20160816010309.zstrljqknc3vjziq@sigill.intra.peff.net>
- In-Reply-To
- <xmqqr39pejhk.fsf@gitster.mtv.corp.google.com>
On Mon, Aug 15, 2016 at 03:48:55PM -0700, Junio C Hamano wrote:
Show 26 quoted lines
> Jeff King <peff@peff.net> 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 big; I won't > > accept this". And then they push in a loop, as before. You've accepted > > the incoming pack into the repository by the time the pre-receive runs. > > You can't just delete it, because you don't know if other simultaneous > > processes have started to depend on the objects. > > > > To solve that, I have patches that put incoming packfiles into a > > "quarantine" area, then run the connectivity check and pre-receive hooks > > with the quarantine accessible via GIT_ALTERNATE_OBJECT_DIRECTORIES. And > > then we either move the quarantine packs into the real repo, or blow > > away the tmpdir, depending on whether the hooks said the objects were > > OK. > > > > Those are patches I plan to share upstream but just haven't gotten > > around to yet. > > I think these other patches can come later, independent from this > three-patch series resurrected from the archive, so I can take a > reroll of these once the integer-size issues you pointed out are > sorted out.
Yeah, definitely it's independent. I was mostly suggesting to Christian that he may want to look into the "easy" register_tempfile() case, as GitLab may find this is only half of the fix that they want.
Also a patch I may try to polish and share in the future, but not as high priority as some of the other stuff.
-Peff