Jeff King <peff@xxxxxxxx> writes: > On Thu, Aug 24, 2017 at 12:27:52AM -0700, Jacob Keller wrote: > >> > For the sneaker-net case, you are much better off generating a single >> > pack and then using "split" and "cat" to reconstruct it on the other end >> > Not that I think we should go into such detail in the manpage, but I >> > have to wonder if --max-pack-size has outlived its usefulness. The only >> > use case I can think of is a filesystem that cannot hold files larger >> > than N bytes. >> >> Is it possible to detect on the file system that we can't store files >> that large, and remove the option, while enabling it only when we >> detect the filesystem is unable to store large files? > > I'm not sure how easy it would be to do such a check. But even if it > was, I'm not sure that buys us much. We'd still carry the code. We could > in theory remove the option, simplifying the interface. But that removes > the possibility of somebody wanting to stage the smaller packfiles on a > more capable filesystem in preparation for moving them to the > more-limited one. I agree that it would not help anybody to _disable_ --max-pack-size feature for those on certain filesystems, but it _might_ make sense to automatically _enable_ it (and set it to the maximum number) when your destination filesystem is limited. Even in that case, failing with an error code from the filesystem and then asking the user to redo with --max-pack-size specified wouldn't be the end of the world, though.
