Re: GSoC Git Proposal Draft - ZheNing Hu

From: Jeff King <peff@peff.net>
To: ZheNing Hu <adlternative@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Christian Couder <christian.couder@gmail.com>,
	Hariom verma <hariom18599@gmail.com>,
	Shourya Shukla <periperidip@gmail.com>,
	olyatelezhnaya@gmail.com
Subject: Re: GSoC Git Proposal Draft - ZheNing Hu
Date: Wed, 7 Apr 2021 15:28:31 -0400	[thread overview]
Message-ID: <YG4H3wXI8pZT+zDI@coredump.intra.peff.net> (raw)
In-Reply-To: <CAOLTT8R_kmdNhJaMjj60H0SEzs6-KrzTQhBHzShQ82aoDa5vzw@mail.gmail.com>

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

> >   - 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).

> 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