Re: FORMAT_PATCH_NAME_MAX increase
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 30, 2017, 13:28 UTC
- Message-ID
- <xmqqk24ybhjj.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <70d34f37-7209-e392-c269-21a61228a041@redhat.com>
Laszlo Ersek <lersek@redhat.com> writes:
Show 10 quoted lines
> The problem is that I can't really automate the subject munging. The > concrete subjects in this case were: > >> OvmfPkg/QemuFwCfgLib: Implement SEV internal function for SEC phase >> OvmfPkg/QemuFwCfgLib: Implement SEV internal functions for PEI phase >> OvmfPkg/QemuFwCfgLib: Implement SEV internal function for Dxe phase > ... > So, even in kernel land, if subjects up to 75 columns are permitted, but > FORMAT_PATCH_NAME_MAX is 64, conflicts are possible, at least in theory, > aren't they? With the numbers stripped, of course.
Yup, configurable lengthening or unconditional lengthening to 75 or so do not sound _too_ bad.
If I sounded like I was opposed to lengthening, that wasn't what I meant. It was more like "if you can meaningfully abbreviate, you may help not just format-patch filenames but other use cases, and you might even be able to get away without lengthening"; if there is no meaningful way to abbreviate, raising the max length may be the only workable solution.