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>
Subject: Re: [PATCH 4/6] [GSOC] ref-filter: add %(rest) atom and --rest option
Date: Mon, 7 Jun 2021 21:02:28 +0800 [thread overview]
Message-ID: <CAOLTT8S+5m+-XF-AcQi9t8njTvyDYzHt=BU+4OPcvTT27RP6dw@mail.gmail.com> (raw)
In-Reply-To: <xmqq7dj6w7a6.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> 于2021年6月7日周一 下午1:52写道:
>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > In order to let "cat-file --batch=%(rest)" use the ref-filter
> > interface, add %(rest) atom for ref-filter and --rest option
> > for "git for-each-ref", "git branch", "git tag" and "git verify-tag".
> > `--rest` specify a string to replace %(rest) placeholders of
> > the --format option.
>
> I cannot think of a sane reason why we need to allow "%(rest)" in
> anithing but "cat-file --batch", where a natural source of %(rest)
> exists in its input stream (i.e. each input record begins with an
> object name to be processed, and the rest of the record can become
> "%(rest)").
>
First of all, although %(rest) is meaningless in ordinary circumstances,
ref-filter must learn %(rest), it is impossible for us to leave the parsing
of %(rest) in cat-file.c alone.
Then, `--rest` is a strategy that make %(rest) can use in `git for-each-ref`
or `git branch -l`. As you said, it is just a boring placeholder used for string
replacement. We can make it output only empty content, If we really don’t
need `--rest`.
> The "cat-file --batch" thing is much more understandable. You could
> for example:
>
> git ls-files -s |
> sed -e 's/^[0-7]* \([0-9a-f]*\) [0-3] /\1 /' |
> git cat-file --batch='%(objectname) %(objecttype) %(rest)'
>
s/[0-3] /[0-3]\t/
> to massage output from "ls-files -s" like this
>
> 100644 c2f5fe385af1bbc161f6c010bdcf0048ab6671ed 0 .cirrus.yml
> 100644 c592dda681fecfaa6bf64fb3f539eafaf4123ed8 0 .clang-format
> 100644 f9d819623d832113014dd5d5366e8ee44ac9666a 0 .editorconfig
> ...
>
> into recods of "<objectname> <path>", and each output record will
> replay the <path> part from each corresponding input record.
>
Yeah, the <path> in the input will be treated as "rest".
> Unless for-each-ref family of commands read the list of refs that it
> shows from their standard input (they do not, and I do not think it
> makes any sense to teach them to), there is no place to feed the
> "rest" information that is associated with each output record. The
> only thing the commands taught about %(rest) by this patch can do is
> to parrot the same string into each and every output record. I am
> not seeing what this new feature is attempting to give us.
>
"parrot the same string"? I think we should use an empty string here,
"parrot the same string" more like what the "git log --format" family does.
> If anything, I would imagine that it would be a very useful addition
> to teach the ref-filter machinery an ability to optionally error out
> depending on the caller when the caller attempts to use certain
> placeholder. Then, we can reject "git branch --sort=rest" sensibly,
> instead of accepting "git branch --sort=rest --rest=constant", which
> is not technically wrong per-se, but smells like a total nonsense from
> practical usefulness's point of view.
>
This sounds like it might help `cat-file` to reject some useless atoms
like %(refname). So something like:
$ git for-each-ref --format="%(objectname) %(objectsize)"
--refject-atoms="%(objectsize) %(objectname)"
will fail.
"git for-each-ref" family use hardcoded to reject %(rest).
I can try to achieve this function.
> > - [--list] [<pattern>...]
> > + [--list] [<pattern>...] [--rest=<rest>]
> > 'git branch' [--track | --no-track] [-f] <branchname> [<start-point>]
> > 'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
> > 'git branch' --unset-upstream [<branchname>]
> > @@ -298,6 +298,10 @@ start-point is either a local or remote-tracking branch.
> > and the object it points at. The format is the same as
> > that of linkgit:git-for-each-ref[1].
> >
> > +--rest=<rest>::
> > + If given, the `%(rest)` placeholders in the `--format` option
> > + will be replaced.
>
> If not given, what happens?
Will output an empty string.
Hope we can reach an agreement:
delete `--rest` and add `--reject-atoms`. ;-)
Thanks.
--
ZheNing Hu
next prev parent reply other threads:[~2021-06-07 13:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-05 9:13 [PATCH 0/6] [GSOC][RFC] ref-filter: add %(raw:textconv) and %(raw:filters) ZheNing Hu via GitGitGadget
2021-06-05 9:13 ` [PATCH 1/6] [GSOC] ref-filter: add obj-type check in grab contents ZheNing Hu via GitGitGadget
2021-06-05 9:13 ` [PATCH 2/6] [GSOC] ref-filter: add %(raw) atom ZheNing Hu via GitGitGadget
2021-06-08 5:07 ` Junio C Hamano
2021-06-08 6:10 ` ZheNing Hu
2021-06-05 9:13 ` [PATCH 3/6] [GSOC] ref-filter: use non-const ref_format in *_atom_parser() ZheNing Hu via GitGitGadget
2021-06-05 9:13 ` [PATCH 4/6] [GSOC] ref-filter: add %(rest) atom and --rest option ZheNing Hu via GitGitGadget
2021-06-05 15:20 ` Hariom verma
2021-06-06 4:58 ` ZheNing Hu
2021-06-07 5:52 ` Junio C Hamano
2021-06-07 13:02 ` ZheNing Hu [this message]
2021-06-07 13:18 ` ZheNing Hu
2021-06-08 6:16 ` ZheNing Hu
2021-06-08 6:59 ` Junio C Hamano
2021-06-08 12:39 ` ZheNing Hu
2021-06-09 7:00 ` Junio C Hamano
2021-06-09 12:47 ` ZheNing Hu
2021-06-08 6:50 ` Junio C Hamano
2021-06-08 12:32 ` ZheNing Hu
2021-06-05 9:13 ` [PATCH 5/6] [GSOC] ref-filter: teach grab_sub_body_contents() return value and err ZheNing Hu via GitGitGadget
2021-06-05 9:13 ` [PATCH 6/6] [GSOC] ref-filter: add %(raw:textconv) and %(raw:filters) ZheNing Hu via GitGitGadget
2021-06-05 10:29 ` [PATCH 0/6] [GSOC][RFC] " Bagas Sanjaya
2021-06-05 13:19 ` ZheNing Hu
2021-06-07 5:55 ` Junio C Hamano
2021-06-07 13:06 ` ZheNing Hu
2021-06-08 6:42 ` Junio C Hamano
2021-06-08 12:52 ` 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='CAOLTT8S+5m+-XF-AcQi9t8njTvyDYzHt=BU+4OPcvTT27RP6dw@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 \
/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).