On 2021-04-15 at 21:20:17, Bruno Albuquerque wrote:
> Sometimes it is useful to get information of an object without having to
> download it completely.
> 
> Add the "object-info" capability that lets the client ask for
> object-related information with their full hexadecimal object names.
> 
> Only sizes are returned for now.
> 
> Signed-off-by: Bruno Albuquerque <bga@google.com>
> ---
>  Documentation/technical/protocol-v2.txt |  31 +++++++
>  Makefile                                |   1 +
>  protocol-caps.c                         | 115 ++++++++++++++++++++++++
>  protocol-caps.h                         |  10 +++
>  serve.c                                 |   2 +
>  t/t5701-git-serve.sh                    |  26 ++++++
>  6 files changed, 185 insertions(+)
>  create mode 100644 protocol-caps.c
>  create mode 100644 protocol-caps.h
> 
> Hello.
> 
> This is my first git patch so I thought I would introduce myself. I am a
> software engineer at Google and I have been involved with opensource for
> a while (mostly with the Haiku OS project) and now I am working on some
> Git changes that hopefully will be generally usefull.
> 
> For this specific change, a clear usage scenario is implementing a VFS
> on top of Git (something like https://github.com/microsoft/VFSForGit) in
> a way that would not require someone to always fully download objects to
> get information about them. Object size is the obvious one and what is
> implemented here.

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.

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.

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.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US