The git tree is the source code

Git offers a method to do a git checkout without getting full history known as a shallow clone. It's fast and allows you to later get the rest of history if you need to merge the tree later on. Secondly if you haven't been importing binary files into your repository even years worth of changes tends to compress very effectively to the point where the space taken up by old revisions is a small multiple of the most recent revision.

I find it hard to believe that arguing tarballs are the preferred form of source code for a project otherwise developed with git would pass the balance of probabilities test in a civil case. After all, as mentioned elsewhere the other side just needs to ask your developers what they use to work with the source code. Even if they reply with a different revision control system, that indicates that you should be publishing your changes from it instead.

Having said that, if internally you *actually* don't use *any* revision control system, then yeah, maybe for you the preferred form really is tarballs.