Philippe Mathieu-Daudé <phi...@redhat.com> writes:
> On 5/14/19 5:48 PM, Alex Bennée wrote: >> >> Aleksandar Markovic <aleksandar.m.m...@gmail.com> writes: >> >>> On May 10, 2019 8:57 PM, "Richard Henderson" <richard.hender...@linaro.org> >>> wrote: >>>> >>> >>> Please change the title to 'target/mips: Switch to using >>> mips_cpu_tlb_fill()', or something along that line. >> >> It does seem a little redundant as "target/mips:" already marks it as a >> mips specific change and viewing the log you can see a series of >> architectures being converted to a new API. >> >>> Also, the reason for changing the field access_type to mips_access type >>> should be explained in the commit message. >> >> ok >> >>> This commit message is generally poor, as it explains relatively >>> unimportant logging issue, while not explaining the core of the >>> change. >> >> Surely the core of the change is explained in the main patches that >> introduce the new API? I think it would be redundant to repeat that for >> every individual architecture touched. It's a shame it's hard to >> explicitly reference a patch in the same series as the commit hashes are >> not yet permanent. At least when we fix things referring to the short >> hash of the original commit is fairly easy. > > Except in the case the maintainer is sending a pull request (like here) > where he can manually fix the commits. Still this is a PITA... If there was tooling that can go from a patch series to a pull request then maybe. But generally a PR is a series of patches that have now passed some standard and can now be sent. I'm not sure I'd want to go over all my commits and re-edit the messages at that point. -- Alex Bennée