Junio C Hamano <gitster@xxxxxxxxx> 于2021年6月9日周三 下午3:00写道： > > I think I kind-of see what is going on here. There is > > git cat-file blob --textconv --path="$path" "$blob_object_name" > > that allows a blob to be fed to the command, pretend as if it > appears at $path in a tree object and grab attribute for it, and > show the blob contents converted using the textconv filter. If we > were to mimic it by extending the format based substitutions, a > design consistent with the behaviour is to teach --format=%(raw) > to show the contents after applying the textconv filter instead of > the raw blob contents. > Yes, this is exactly what cat-file --textconv does. > And there is a corresponding > > git cat-file --batch --textconv > > The "--path=$path" parameter is omitted when using --batch, as each > object would sit at different path in the tree (so the input stream > would be given as a run of "<blob> <path>" to give each item its own > path). > Just like let --batch omitted --path, --rest is meaningless for "for-ech-ref". > So to answer my question in the previous message, yes, this is an > attempt to support the "cat-file --textconv". So in the context of > that command, something may need to be added. But I do not think it > makes any sense to expose that to for-each-ref and friends, even if > we were to share the internal machinery (after all, sharing of the > internal machinery is a mere means to an end that is to make it > easier to give the same syntax and same behaviour to end users and > is not a goal itself; "because we use the same machinery, the users > have to tolerate that irrelevant %(atoms) are accepted by the parser" > is not making a good excuse for a sloppy implementation). > Because "git cat-file --batch" will only print the contents of the object once, so when implements the function of textconv/filters in ref-filter, we should really consider whether we should let something like "%(raw) %(raw) %(raw) %(raw:size)" all pass the conversion of textconv/filters. If it is my previous %(raw:textconv) or %(raw:filter), they can only print the converted content separately, and we need: $ git for-ecah-ref --format="%(raw:filters) %(raw:filters) %(raw:filters) %(raw:filters:size)" As you said it might be too complicated for the user.... > Having said all that, I somehow doubt that the "--batch=<format>" > was designed to interact sensibly with the "--textconv" option. > builtin/cat-file.c::expand_atom() does not know anything at all that > the data could be modified from the raw contents of the blob, so > --batch="%(contents) %(size)" --textconv, if existed, may show the > conveted contents with size of blob before conversion, or something > incoherent like that. And if your rewrite using the shared internal > machinery results in a more coherent behaviour, that would be > excellent. For example, we could imagine that the machinery, when > textconv (or filter) is in use, would first grab the blob contents > and run the requested conversion, and then work solely on that > conveted contents when computing what to fill with %(raw:size) and > other blob-related atoms. > And with your --textconv/--filters, we only need: $ git for-ecah-ref --format="%(raw) %(raw) %(raw) %(raw:size)" --filters This will be more concise for users. I will try to build --filters, --textconv for ref-filter . But as stated in the previous reply, it needs to be placed after the transplant of cat-file --batch (Because --path is useless for for-each-ref, and at the same time we need proper testing for --filter/--textconv.) Thanks, your reply is very reasonable, -- ZheNing Hu
