Hi, On Sun, Jun 27, 2021 at 6:06 PM ZheNing Hu via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > In order to let cat-file use ref-filter logic, let's do the > following: > > 1. Change the type of member `format` in struct `batch_options` > to `ref_format`, we will pass it to ref-filter later. > 2. Let `batch_objects()` add atoms to format, and use > `verify_ref_format()` to check atoms. > 3. Use `format_ref_array_item()` in `batch_object_write()` to > get the formatted data corresponding to the object. If the > return value of `format_ref_array_item()` is equals to zero, > use `batch_write()` to print object data; else if the return > value is less than zero, use `die()` to print the error message > and exit; else if return value is greater than zero, only print > the error message, but don't exit. > 4. Use free_ref_array_item_value() to free ref_array_item's > value. > > Most of the atoms in `for-each-ref --format` are now supported, > such as `%(tree)`, `%(parent)`, `%(author)`, `%(tagger)`, `%(if)`, > `%(then)`, `%(else)`, `%(end)`. But these atoms will be rejected: > `%(refname)`, `%(symref)`, `%(upstream)`, `%(push)`, `%(worktreepath)`, > `%(flag)`, `%(HEAD)`, because our objects don't have a refname. It's not clear why some atoms are rejected? Are we going to support them in later commits? (or sometime in the future) OR We are never going to support them. Because they make no sense to cat-file? (or whatever the reason) Whatever is the reason, I think it's a good idea to include it in the commit message. -- Hariom
