Re: [PATCH 2/5] bundle: support fsck message configuration
- From
Justin Tobler <jltobler@gmail.com>
- Date
- Nov 22, 2024, 15:44 UTC
- Message-ID
- <4icigeb6n75pbxqmpp3uynooef7dff2f73lxmrjjmppuz7hibo@bwb3tkffnqop>
- In-Reply-To
- <xmqqttc0cawy.fsf@gitster.g>
On 24/11/22 10:30AM, Junio C Hamano wrote:
Show 12 quoted lines
> Justin Tobler <jltobler@gmail.com> writes: > > > if (opts.flags & VERIFY_BUNDLE_FSCK) > > - strvec_push(&ip.args, "--fsck-objects"); > > + strvec_pushf(&ip.args, "--fsck-objects%s", > > + opts.fsck_msg_types ? opts.fsck_msg_types : ""); > > OK, having %s immediately after --option-name means that anybody who > is adding anything to fsck_msg_types is responsible for starting it > with an "=" equals sign, but that is in line with how existing code > does, e.g. receive-pack drives unpack-objcts/index-pack with the > "--strict%s" option with a potential value for fsck_msg_types).
I was considering making it the responsibility of the `fsck_msg_types` consumer to conditionally preprend the '='. This would mean that fetch-pack, in the later patch, should also be updated to not automatically prepend '=' when parsing the config and be adjusted accordingly. This does feel more intuitive to me, but I've not sure it warrants the added fallout and complexity.
In the next version I'll add a comment to the type definition indicating that any value for `fsck_msg_types` other than NULL, is expected to be prefixed with '='. I am open to changing how this works altogether though if we think that is best. :)
-Justin