On 22/04/18 17:12, Duy Nguyen wrote: > On Sun, Apr 22, 2018 at 5:58 PM, Ramsay Jones > <ram...@ramsayjones.plus.com> wrote: >>>> I think you need to try a little harder than this! ;-) >>> >>> Yeah. I did think about grepping the output but decided not to because >>> of gettext poison stuff and column output in "git help". If we do want >>> to test this, how about I extend --list-cmds= option to take a few >>> more parameters? --list-cmds=common would output all common commands, >>> --list-cmds=<category> does the same for other command category. This >>> way we can verify without worrying about text formatting, paging or >>> translation. >> >> Hmm, my immediate reaction would be to prefer my simple tests. >> Yes, they are not exactly rigorous and they would be affected >> by changing the help formatting, but they are effective. ;-) >> >> [I don't think the formatting would change that often, or at >> all - whoever submits that patch would get to update the tests!] > > Hmm.. for non-column output that's true. "git help" with column output > should probably fine as well because even though we add more and more > commands every month, these are not marked common (and unlikely so). > So yeah I agree. > >> What did you think about adding the BUG() checks? > > I was thinking if there was a way to fail the build after running > ./generate-cmds.sh and generating empty output but it does not sound > easy to do. So yeah, BUG() checks sound good.
Yeah, failing the build would be preferable, but I didn't get that far. ;-) [BTW, I just applied your patch series to the 'next' branch (I just couldn't be bothered to revert your last series from the 'pu' branch, etc.) and, as expected, everything built OK, passed the test-suite and 'git help' is working just fine.] Thanks! ATB, Ramsay Jones
