Junio C Hamano [off-list ref] writes:
As I already said, I do not think %(contents) mixes well with this
use for trees and blobs where you give the raw bytes, since
%(contents) for commit and tag objects was never about the full byte
sequence of the object. It was to give the unstructured part meant
for human consumption, stripping the structured "header" part of the
object.
To extend on this point a bit (even though this is not all that
urgent during the prerelease freeze), conceptually, the %(content)
field is understood in the larger picture like this:
+--- (the whole thing) ----------------------------------------------+
| |
| +--- "header" ---------------------------------------------------+ |
| | tree 678c03dca0a26afd746e8c8bb9e4aadc8bf479b1 | |
| | parent 378c7c6ad48c4ccddf9b534616a0e86f28440bd3 | |
| | author Junio C Hamano [off-list ref] 1621675665 +0900 | |
| | committer Junio C Hamano [off-list ref] 1621675741 +0900 | |
| +----------------------------------------------------------------+ |
| |
| +--- "contents" -------------------------------------------------+ |
| | | |
| | +--- "subject" ----------------------------------------------+ | |
| | | Git 2.32-rc1 | | |
| | +------------------------------------------------------------+ | |
| | | |
| | +--- "body" -------------------------------------------------+ | |
| | | Signed-off-by: Junio C Hamano [off-list ref] | | |
| | +------------------------------------------------------------+ | |
| | | |
| +----------------------------------------------------------------+ |
| |
+--------------------------------------------------------------------+
Even though %(header), when it is invented, would make perfect sense
for commits and tags, it will never make sense for trees and blobs.
Which means "contents", which is "the whole thing except for the
header part", would not, either.
There is no %(placeholder) to ask for "the whole thing", and that is
what you want to use for cat-file --batch if I am not mistaken, and
adding one would be a good idea. There is no %(header) yet, either,
but if somebody needs it for their scripts, it is clear where it fits
in the picture.
To extend on this point a bit (even though this is not all that
urgent during the prerelease freeze), conceptually, the %(content)
field is understood in the larger picture like this:
+--- (the whole thing) ----------------------------------------------+
| |
| +--- "header" ---------------------------------------------------+ |
| | tree 678c03dca0a26afd746e8c8bb9e4aadc8bf479b1 | |
| | parent 378c7c6ad48c4ccddf9b534616a0e86f28440bd3 | |
| | author Junio C Hamano [off-list ref] 1621675665 +0900 | |
| | committer Junio C Hamano [off-list ref] 1621675741 +0900 | |
| +----------------------------------------------------------------+ |
| |
| +--- "contents" -------------------------------------------------+ |
| | | |
| | +--- "subject" ----------------------------------------------+ | |
| | | Git 2.32-rc1 | | |
| | +------------------------------------------------------------+ | |
| | | |
| | +--- "body" -------------------------------------------------+ | |
| | | Signed-off-by: Junio C Hamano [off-list ref] | | |
| | +------------------------------------------------------------+ | |
| | | |
| +----------------------------------------------------------------+ |
| |
+--------------------------------------------------------------------+
Thank you for providing such a complete view. This also means
that the "raw" of contents and tag will contain two parts: "header"
and "contents". But for blobs and trees, they don’t have these things.
Even though %(header), when it is invented, would make perfect sense
for commits and tags, it will never make sense for trees and blobs.
Which means "contents", which is "the whole thing except for the
header part", would not, either.
Although we don’t have a %(header), but in fact we already have fragments
of "%(numparent)", "%(parent)" %(tree)" (see grab_commit_values()) and
"%(tag)"," %(type)","%(object)" (see grab_tag_values()), but they are not
obtained through the "header" part of the raw object buffer.
There is no %(placeholder) to ask for "the whole thing", and that is
what you want to use for cat-file --batch if I am not mistaken, and
adding one would be a good idea. There is no %(header) yet, either,
but if somebody needs it for their scripts, it is clear where it fits
in the picture.
So I don't know if adding %(header) will cause duplication of functions.
Thanks!
--
ZheNing Hu
ZheNing Hu [off-list ref] 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.
But nobody is asking for it right now, and your cat-file --batch
does not need it right away.
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.
Junio C Hamano [off-list ref] 于2021年5月26日周三 上午1:11写道：
ZheNing Hu [off-list ref] writes:
quoted
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