On Sun, Jan 22 2023, René Scharfe wrote: > Am 22.01.23 um 08:48 schrieb Jeff King: >> We probably also should outright reject gigantic trees, >> which closes out a whole class of integer truncation problems. I know >> GitHub has rejected trees over 100MB for years for this reason. > > Makes sense. I really don't think it does, let's not forever encode arbitrary limits in the formats because of transitory implementation details. Those sort of arbitrary limits are understandable for hosting providers, and a sensible trade-off on that front. But for git as a general tool? I'd like to be able to throw whatever garbage I've got locally at it, and not have it complain. We already have a deluge of int v.s. unsigned int v.s. size_t warnings that we could address, we're just choosing to suppress them currently. Instead we have hacks like cast_size_t_to_int(). Those sorts of hacks are understandable as band-aid fixes, but let's work on fixing the real causes.
