git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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