Week 12: How ref-filter does things
The past week, I have been rerolling the mailmap commit in my fork according to
comments it recieved. I think it has taken more form now and we can send it to
the mailing list soon. Although I guess the patch cycle will go well after
Git-2.42.0 (which is in less than a week from now, so). The lastest of the
rerolls in the fork is “mailmap4”.
The majority of the work that I did this week was on Hariom’s idea.
Setting the stage
So, all the way back in the “Week 2” post, I wrote about an idea that Hariom came up with regarding a bridge between the ref-filter formats and the pretty formats, where we essentially do something like
if (ref-filter format exists)
grab values from ref-filter
else
do it the pretty way
this helps in testing, say log
output, which is generated from the logic of
ref-filter
.
My approach (kind of)
The way ref-filter
does things out of any filtering of refs is that, it first
gathers the format in
git for-each-ref --format=<format> refspec
and verifies that format, which parses the options if we have a legitimate format and then we grab the values according our format.
pretty
also works in a similar way but is more straight-forward, there are
calls to the core format_commit_one()
which strips off the placeholder string
till all the placeholders are parsed. The values themselves are also grabbed in
format_commit_one()
.
Hariom did work on pretty-lib.{c, h}
, which prints out the log
based on the
values grabbed from ref-filter
. One of the functions used in the
implementation is convert_format()
, which converts the pretty
formats to
their equivalent ref-filter
formats.
The implementation that I’m working on now makes use of this convert_format()
function, but instead of returning the length of the placeholder, it returns the
format string as known to ref-filter. We run verify_ref_format()
on such a
string and grab the values from ref-filter.
To make this work, we would need to find a way in ref-filter
where we could
grab values for a given format without a ref but with the commit id, which I’m
currently working on.
Once this is done, we run a check whether the whole pretty
format string is
transformable into ref-filter
format string. If not, we fall back to doing
things pretty way and finally print the values for example a log
output. We
can do this two ways
- Reject
ref-filter
logic if at least onepretty
format doesn’t have an equivalent inref-filter
for the given format string. - Reject
ref-filter
logic for only thosepretty
placeholders in the format string that don’t have an equivalent inref-filter
and grab values accordingly, that is, for those that have an equivalent inref-filter
grab values throughref-filter
logic and for those who don’t, fallback topretty
way of doing things.
The first way is relatively easier but the second way can be followed given how
convert_format()
is written.
I haven’t discussed this with Christian and Hariom yet, wanted to do it once the
I pushed the commits. Throughout the week, we discussed the mailmap support to
ref-filter
.
‘til next time,
Kousik