Some testing comments:

• Commits that touch a ton of files? I just wonder if there's any limit to the input that git diff-tree and git cat-file will accept.
• Commits that delete files? Not sure if these commands do anything goofy on deleted files, and in theory they should still work since the underlying objects should still exist in the object DB. As a micro-optimization we could skip checking deletes entirely by (I think) checking the "change mode" output from git diff-tree.
• Races on git repack? Are we worried about git commands that reorganize the object DB on disk running concurrently with these commands (see question about objectsize vs objectsize:disk).

Commits that touch a ton of files? I just wonder if there's any limit to the input that git diff-tree and git cat-file will accept.

I think this will first break when the total output size of git diff-tree is larger than 2GB and we hit the PHP 2GB string size limit.

This can be a single file (see T10832 for a previous Git vulnerability with 2GB paths) but it's unlikely that a 2GB path is legitimate.

For normal path lengths (producing ~512 byte lines) this is ~4M files in a single commit. It seems unlikely that we'll encounter this. If we do, the cause (or, at least, the reproduction case) should be reasonably obvious from examining the commit and seeing that it touches 4M files. We could switch to LinesOfALargeExecFuture to work around this and probably increase the limit to "however much memory the machine has", or we could add an output limit and throw if a commit has more than 1GB of paths AND has filesize limits enabled ("Touch fewer paths or disable filesize limits to push this unusually large change.")

(Maybe I'll just switch this to LinesOfALargeExecFuture when I move it into a separate LowLevelQuery anyway since it's not an especially complicated change, although the internal \0 delimiting is slightly awkward.)

Commits that delete files?

These work properly already, the new file gets the empty hash (0000...0000) and we explicitly short circuit this into a filesize of 0 bytes (there's no particular reason for this specific behavior right now -- it just makes sure that we never hit any filesize limit for deleted files -- but if we later add a "maximum number of files a commit may touch" limit or something it might be useful to care about this in some way).

Are we worried about git commands that reorganize the object DB on disk running concurrently with these commands?

I don't believe this is a concern.

I think the objectsize stuff is talking about using %(objectsize) when the object is a commit. Commits don't have an unambiguous "size" and I'm guessing (?) that their "size" is some sort of amalgamation of things that are size-like plus some hand waving.

The objectsize value when the object is a blob consistently appears to be the number of bytes in the file, as we'd expect. In my local working copy of Phabricator, every blob has the same size on disk and %(objectsize) (I'm skipping symlinks because filesize() resolves them, I could probably use stat() or something instead to get their disk size accuately). The value of %(objectsize:disk) is some kind of weird internal Git artifact:

<?php

require_once 'scripts/init/init-script.php';

list($paths) = execx('git ls-tree -r HEAD | awk %s', '{print $3 " " $4}');
$paths = trim($paths);
$paths = explode("\n", $paths);

foreach ($paths as $path) {
  list($hash, $path_name) = explode(' ', $path, 2);
  $disk_size = filesize($path_name);

  if (is_link($path_name)) {
    continue;
  }

  list($git_sizes) = execx(
    'echo %s | git cat-file --batch-check=%s',
    $hash,
    '%(objectsize) %(objectsize:disk)');
  $git_sizes = trim($git_sizes);
  list($git_object_size, $git_disk_size) = explode(' ', $git_sizes, 2);

  echo sprintf(
   "%4s % 16d % 16d % 16d %s\n",
   ((int)$disk_size === (int)$git_object_size ? '' : '****'),
   $disk_size,
   $git_object_size,
   $git_disk_size,
   $path_name);
}

...produces:

$ php -f test.php 
                  109              109               98 .arcconfig
                 1814             1814              132 .arclint
                   98               98               75 .arcunit
                  678              678              287 .editorconfig
                  858              858              453 .gitignore
                10173            10173               24 LICENSE
                  739              739              378 NOTICE
                 1221             1221              246 README.md
                 2010             2010              145 conf/__init_conf__.php
                  713              713              349 conf/aphlict/README
                  450              450              182 conf/aphlict/aphlict.default.json
                    0                0                9 conf/keys/.keep
                   44               44               54 conf/local/README
                 1584             1584              789 externals/JsShrink/jsShrink.php
                  695              695              409 externals/JsShrink/readme.txt
                22840            22840              689 externals/amazon-ses/ses.php
                  931              931              578 externals/cowsay/ChangeLog
                  385              385              262 externals/cowsay/INSTALL
                 1116             1116              610 externals/cowsay/LICENSE
                  445              445              286 externals/cowsay/MANIFEST
                 1610             1610              894 externals/cowsay/README
                  879              879              466 externals/cowsay/Wrap.pm.diff
                  123              123               99 externals/cowsay/cows/bunny.cow
...<many more lines of output with no differences between disk size and `%(objectsize)`> ...

it seems like using objectsize will allow small changes to existing huge objects to go through

I think this would be bad (even if the behavior itself isn't objectively "bad", it's definitely confusing/unexpected) but, consistent with the behavior of %(objectsize) above, it doesn't appear to be what happens in practice. %(objectsize) always reports the number of bytes in the file so making a 1-byte change to a 1GB file produces an error if the filesize limit is <1GB. Note that you can still remove the file, and your changes goes through if you delete enough bytes to get the file under the limit. You just aren't allowed to end up with any 1GB+ files on disk after your change applies.

One case we might want to refine is that we could let you touch file xyz.c if the old version of xyz.c was already over the limit: once you sneak a 1GB file into the repository, you might be allowed to keep modifying it. But I'd like to see a really, really good use case for this before adding support.