ZheNing Hu <adlternative@xxxxxxxxx> writes: > ZheNing Hu <adlternative@xxxxxxxxx> 于2021年6月7日周一 下午9:18写道： >> >> ZheNing Hu <adlternative@xxxxxxxxx> 于2021年6月7日周一 下午9:02写道： >> > >> > Hope we can reach an agreement: >> > delete `--rest` and add `--reject-atoms`. ;-) >> > >> >> I forget one thing: %(raw:textconv) and %(raw:filters) can use >> the value of "--rest" as their <path>. But now if we want delete --rest, >> they can not be used for "for-each-ref" family, Git will die with >> "missing path for 'xxx'". >> > > If we actually delete "--rest", we will have no way to test %(raw:textconv) > and %(raw:filters)... So now I think we can keep --rest (or use > another name --path) > and let "git for-each-ref" family reject %(rest) by default. I didn't read beyond the %(rest) thing, but do we even need %(raw:textconv) to begin with? It is totally useless in the context of for-each-ref because textconv by its nature is tied to attributes that by definition needs a blob that is sitting at a path, but the objects for-each-ref and friends visit are mostly commits and tags, and even for refs that point at a blob, there isn't any "path" information to pull attribute for. Is that what you want to add to give "cat-file --batch"? Even in the context of "cat-file --batch", you can throw an object name for a blob to the command, but there is no path for the blob (a blob can appear at different places in different trees---think "rename), so I am not sure what benefit you are trying to derive from it. Thanks.
