On Thu, Feb 04 2021, Hariom verma wrote:
> Hi,
>
> On Sun, Jan 31, 2021 at 2:15 AM Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> wrote:
>>
>> Given that the goal of this series is to unify this parsing logic
>> between log/for-each-ref, why do we need to then copy/paste the exact
>> same docs we have in pretty-formats.txt?
>>
>> At the very least we should move this to pretty-formats-trailers.txt or
>> something, and just include it in both places, or better yet just refer
>> to the relevan parts of "git log"'s man page, no?
>
> Ok. I will refer to the trailers part of "pretty-formats"'s man page
> in "git-for-each-ref"'s man page.
Sure, FWIW you can also (not saying it has to be this) include the same
section in both, maybe with some blurb on the top saying it's not
different between the two...
>> And similarly, here we have now mostly duplicated tests for this between
>> here and t/t4205-log-pretty-formats.sh.
>>
>> I think the right thing to do is to start by moving the tests that are
>> now in t/t4205-log-pretty-formats.sh relevant to this formatting into
>> its own file or something.
>>
>> Then instead of duplicating the tests here, just prepare them to be
>> changed so that we can add both "git log" and a "git for-each-ref"
>> invocation to some for-loop, so we'll test both.
>
> With this unified trailer logic, "git log" and "git for-each-ref"
> still behave differently.
> For e.g.: "git log" does nothing for unknown/incorrect trailer option,
> whereas "git for-each-ref" stops.
>
> Even if we move trailer related tests for both into a new file, I
> guess we still need to test trailers for both "git log" and "git
> for-each-ref" separately?
We have a few tests that define a test function to test these sorts of
cases, t/t3070-wildmatch.sh is one, t/t3800-mktag.sh another.
So you can just do:
test_trailers A '%(trailers:keyonly)' 'Signed-off-by' 'ERR: error from for-each-ref' # (or whatever)
And make the "test_trailers" function do the common setup, have both
"log" and "for-each-ref" look at the "A" tag and assert what their
output is, respectively (or an error, or whatever).
I think that's especially valuable in cases where you have similar
codepaths, because it makes it easy for both the author and reviewers to
eyeball intended an unintended differences.
