Re: [PATCH] object-info: support for retrieving object info

From: Bruno Albuquerque <bga@google.com>
Date: Apr 19, 2021, 21:18 UTC
Message-ID: <CAPeR6H71Hn3ei4CzZLnQH1JGTvTpy6Ru-Mpin5cVJ0_7GSkoag@mail.gmail.com>
In-Reply-To: <YHoJUrqeT26Nihua@camp.crustytoothpaste.net>

On Fri, Apr 16, 2021 at 3:02 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 9 quoted lines

> I want to point out a few notes as someone who's worked on projects
> appurtenant to VFS for Git.  If your goal is to create a VFS, then
> learning what Git thinks the object size is is not helpful.
>
> Git performs all sorts of operations on files when checking them out,
> such as smudge and clean filters (e.g., Git LFS), line ending
> conversion, and working tree encodings (e.g., to and from UTF-16 on
> Windows).  Thus, your VFS must necessarily exclude all of this
> functionality to use Git's concept of an object size as a VFS parameter.

This is, of course, completely valid from a Git-specific point of view but, because we are dealing with a hypothetical remote FS, it would not be unheard of (and, actually, this is most likely the norm more often than not) that when exposing git objects in an actual FS, we would not be doing any conversions whatsoever and would, instead, show everything as it is actually stored on the remote server.

Show 6 quoted lines

> For the average project, the worst functionality to lose is actually
> line ending conversion, since that means people will practically check
> in a mix of line endings unless you are very strict in CI.  VFS for Git
> was originally designed to address the needs of a project that was not
> cross-platform and thus this was not a problem, but these limitations
> are substantial and I wouldn't recommend repeating them.

Although I understand the issue here, this would be fine in the context of a remote filesystem as I see it. In fact this is something that actually has precedent in git anyway ("git cat-file -s" without --filters will emit the size without any conversions).

As long as the size we report match with the actual contents of the file we expose (i.e. without conversions), this looks ok to me.

> So I'm not opposed to seeing this functionality come in if you have
> other plans for it (which is fine and I'm certainly interested in
> hearing about them if you do), but I don't think this is helpful for VFS
> scenarios and shouldn't be used for that purpose.

Thanks for your comments. This actually works for our purposes and, more generally, it would be useful even if you do care about all the conversions (in this case, as a reasonable approximation of the actual disk size I guess).