From: ZheNing Hu <adlternative@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
Git List <git@vger.kernel.org>,
Christian Couder <christian.couder@gmail.com>,
Hariom Verma <hariom18599@gmail.com>,
Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH 2/3] [GSOC] ref-filter: support %(contents) for blob, tree
Date: Wed, 26 May 2021 15:48:59 +0800 [thread overview]
Message-ID: <CAOLTT8RdEive+fCtO-c0fZVjpmaYi0WYMZofCE-8wd94SCrdMg@mail.gmail.com> (raw)
In-Reply-To: <xmqqczteeo11.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> 于2021年5月26日周三 上午1:11写道:
>
> ZheNing Hu <adlternative@gmail.com> writes:
>
> > So I don't know if adding %(header) will cause duplication of functions.
>
> I do not think you can duplicate the feature of %(header) with
> other existing placeholders. You may want to dump the headers of
> series of commits so that you can find if there is any commit with
> unusal header elements, but %(tree), %(parents), etc. would by
> definition be the known ones, so any combination of them will not be
> a substitute.
>
Well, "find if there is any commit with unusal header elements"
is indeed one thing that may need to be done (not now).
I tried to build "%(header)" yesterday and found some problems:
1. These atoms are too "flat":
"tree", "parent", "numparent", "object"... they are all part of the
header, why not use "%(header:tree)" like "%(contents:subject)"
does? Similarly, why not use "%(author:name)" instead of "%(authorname)"...
2. Why is there no state machine to save the parsing state of an object?
`parse_tag_buffer()`, `parse_commit_buffer()`, they only parse part of the
content of the object. E.g. tag parsed "object", "type", "tag" and "taggerdate"
in `parse_tag_buffer()`, but it did not save the starting position and length of
the parsed fields, which caused `grab_person()`, `grab_date()` to parse the
object again and again. I think this may be an optimization point.
> But nobody is asking for it right now, and your cat-file --batch
> does not need it right away.
>
Or we only provide the simplest "%(header)" and "%(header:size)"
(it can be easily supported with "%(raw)"), leaving the other feature
to the future.
> What I wanted to say in the message you are responding to was *not*
> that you would want to add %(header) for completeness right now.
> But thinking beyond your immediate need (i.e. the "whole thing") and
> imagining how various pieces, including the ones that do not exist
> yet, would fit together, would help you to avoid designing the parts
> you immediately need in a way you would regret in the future.
As I said before, many atomic designs are not very regular.
Our ultimate goal may be we can simultaneously support:
"%(raw)"
"%(raw:header)"
"%(raw:header:tagger)"
"%(raw:header:tagger:eamil)"
"%(raw:header:taggereamil)"
"%(header:taggereamil)"
"%(header:tagger:eamil)"
"%(taggereamil)"
"%(tagger:eamil)"
...
Each layer is a namespace. Of course, it may take a long
distance to support this.
Thank.
--
ZheNing Hu
next prev parent reply other threads:[~2021-05-26 7:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-23 9:53 [PATCH 0/3] [GSOC][RFC] ref-filter: add contents:raw atom ZheNing Hu via GitGitGadget
2021-05-23 9:53 ` [PATCH 1/3] [GSOC] quote: add *.quote_buf_with_size functions ZheNing Hu via GitGitGadget
2021-05-23 9:53 ` [PATCH 2/3] [GSOC] ref-filter: support %(contents) for blob, tree ZheNing Hu via GitGitGadget
2021-05-25 5:03 ` Junio C Hamano
2021-05-25 5:47 ` Junio C Hamano
2021-05-25 9:28 ` ZheNing Hu
2021-05-25 17:11 ` Junio C Hamano
2021-05-26 7:48 ` ZheNing Hu [this message]
2021-05-23 9:53 ` [PATCH 3/3] [GSOC] ref-filter: add contents:raw atom ZheNing Hu via GitGitGadget
2021-05-24 1:09 ` [PATCH 0/3] [GSOC][RFC] " Junio C Hamano
2021-05-24 2:41 ` Felipe Contreras
2021-05-24 5:22 ` Bagas Sanjaya
2021-05-24 15:21 ` Junio C Hamano
2021-05-24 13:09 ` ZheNing Hu
2021-05-26 0:56 ` Junio C Hamano
2021-05-26 6:45 ` ZheNing Hu
2021-05-26 7:06 ` Junio C Hamano
2021-05-26 9:17 ` ZheNing Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOLTT8RdEive+fCtO-c0fZVjpmaYi0WYMZofCE-8wd94SCrdMg@mail.gmail.com \
--to=adlternative@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=hariom18599@gmail.com \
--cc=karthik.188@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).