Re: GSoC Git Proposal Draft - ZheNing Hu

From: Jeff King <peff@peff.net>
Date: Apr 7, 2021, 19:28 UTC
Message-ID: <YG4H3wXI8pZT+zDI@coredump.intra.peff.net>
In-Reply-To: <CAOLTT8R_kmdNhJaMjj60H0SEzs6-KrzTQhBHzShQ82aoDa5vzw@mail.gmail.com>

On Sat, Apr 03, 2021 at 10:27:39PM +0800, ZheNing Hu wrote:

Show 15 quoted lines

> >   - figure out which data will be needed for each item based on the
> >     parsed format, and then do the minimum amount of work to get that
> >     data (using "oid_object_info_extended()" helps here, because it
> >     likewise tries to do as little work as possible to satisfy the
> >     request, but there are many elements that it doesn't know about)
> >
> 
> I have indeed noticed that `oid_object_info_extended()`
> can get information about the object which we actually want.
> In `cat-file.c`, It has been used in `batch_object_write()`, and
> `expanding_atom()` specify what data we need.
> In `ref-filter.c`, It has been used in `get_object()`.
> I am not sure what you mean about "many elements that it
> doesn't know about", For the time being, `cat-file` can get 5
> kind of objects info it need.

I think there are things one might want to format that oid_object_info_extended() does not know about. For example, if you are asking about %(authorname), it can't provide that. But we want to do as little work as possible to satisfy the request. So for example, with the format "%(objectsize)", we'd prefer _not_ to load the contents of each object, and just ask oid_object_info_extended() for the size. But if we are asked for "%(authorname)", we know we'll have to read and parse the object contents.

So this notion of "figure out the least amount of work" will have to be part of the format code (and ref-filter and the pretty.c formatters do make an attempt at this; I'm saying that a universal formatter will want to keep this behavior).

Show 6 quoted lines

> Maybe you think that `cat-file` can learn some features in
> `ref-filter` to extend the function of `cat-file --batch`?
> E.g. %(objectname:short)? I think I may have a better
> understanding of the topic of this mini-project now.
> We may not want to port the logic of cat-file,but to learn some
> design in `ref-filter`, right?

Yes, I think the goal is for all of the commands that allow format specifiers to support the same set (at least where it makes sense; obviously you cannot ask for %(refname) in cat-file).

And IMHO the best way to do that is to write a new universal formatting API that takes the best parts from all of the existing ones. It _could_ also be done by choosing ref-filter as the best implementation, slowly teaching it formats the other commands know (which is what Olga had started with), and then cleaning up any performance deficiencies. But I think that last part would actually be easier when starting from scratch (e.g., I think it would help to actually produce an abstract syntax tree of the parsed format, and then walk that tree to fill in the values).

-Peff