Re: [PATCH 0/3] [GSOC][RFC] ref-filter: add contents:raw atom

From: ZheNing Hu <adlternative@gmail.com>
Date: May 24, 2021, 13:09 UTC
Message-ID: <CAOLTT8RgVO44Lf9jtz=8Jj5CxiGqbeAcFQOwQTazZzBwtKTr6A@mail.gmail.com>
In-Reply-To: <xmqq1r9xndjf.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> 于2021年5月24日周一 上午9:09写道：

Show 13 quoted lines

>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > In (a2f3241: [GSOC] ref-filter: add contents:raw atom) I did not notice the
> > ...
>
> Before going into any of these details, remember that the cover
> letter is where you first sell the series to the readers.  Why is it
> worth their time to read it?  What problem does it solve in the
> bigger picture?  Mention that we want to let "cat-file --batch" use
> the ref-filter --format logic, if that is the primary reason why we
> have these three patches, for example.
>

Thanks for reminding, Indeed, as you said, this cover-letter needs to explain the patches' main purpose: let "cat-file --batch" use the ref-filter --format logic.

Show 8 quoted lines

> I actually do not know if a modified form of %(contents) is a good
> match for this feature.  It was invented as a way to extract the
> unstructured "free text" part of structured textual objects (namely,
> commits and tags) so it is natural that it would not apply to trees
> (they are structured and there is no unstractured "free text" part)
> nor blobs (they are totally unstructured and does not even have to
> be text).
>

This is exactly what I worry about: Does %(contents) have good semantics to explain things like blob, tree objects which have no unstractured "free text" part or totally unstructured?

> Is there another word to refer to the entire payload unadulterated?
>

If you specifically mean "raw" in %(contents:raw), I agree with Felipe Contreras or Bagas Sanjaya, "raw" seems to be enough. But if you mean we need another atom name, then "%(binary)", "%(text)" may be possible choices.

There is a good word in `ref-filter.c`: C_BARE, but this enum vale corresponds to %(contents). Therefore, I cannot use the name "%(contents:bare)".

Show 23 quoted lines

> > git for-each-ref --format="%(contents)" --python refs/mytrees/first
> >
> > will output a string processed by python_quote_buf_with_size(), which
> > contains'\0'. But the binary files seem to be useless after quoting. Should
> > we allow these binary files to be output in the default way with
> > strbuf_add()? If so, we can remove the first patch.
>
> The --language option is designed to be used to write a small script
> in the language and used like this:
>
>     git for-each-ref --format='
>                 name=%(refname)
>                 var=%(placeholder)
>                 mkdir -p "$(dirname "$name")"
>                 printf "%%s" "$var" >"$name"
>     ' --shell | /bin/sh
>
> Note that %(refname) and %(placeholder) in the --format string is
> not quoted at all; the "--shell" option knows how values are quoted
> in the host language (shell) and writes single-quotes around
> %(refname).  If %(placeholder) produces something with a single-quote
> in it, that will (eh, at least "should") be quoted appropriately.
>

Well, now I have also noticed that --language can make these atoms be surrounded by single quotes, special characters in the output will be escaped e.g. "a'b" will turn to "'a\'b'", In this way, shell, python... can directly quote the content.

Show 8 quoted lines

> So It does not make any sense not to quote a value that comes from
> %(placeholder), whether it is binary or not, to match the syntax of
> the host language you are making the "for-each-ref --format=" to
> write such a script in.
>
> So, "binary files seem to be useless after quoting" is a
> misunderstanding.  They are useless if you do not quote them.
>

Now I agree that It seems that the content of the blob or tree is meaningful after being quoted.

> Thanks.
>
> P.S. I am mostly offline today, and response will be slow.
>

Thanks! -- ZheNing Hu