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@xxxxxxxxxx> > --- > 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
Attachment:
signature.asc
Description: PGP signature
