Re: [PATCH 2/3] config: values of pathname type can be prefixed with :(optional)

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2025, 20:05 UTC
Message-ID: <xmqq1pt6vkve.fsf@gitster.g>
In-Reply-To: <aBSHugZcH8NusOcI@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 6 quoted lines

> I can see why it may be useful to allow for non-existent paths. But I
> wonder whether we really should be skipping over empty files, as well,
> as it may be assuming too much about the semantics of a given config
> key. In other words, are we reasonably sure that there won't ever be a
> usecase where you may want to specify an optional and empty file? And
> are there any use cases where an empty file should be ignored?

If somebody goes back to the original discussion that happened a few years before the patches were originally written, they might find a use case where it is more convenient to ignore an empty file, but it is an old patch series, so I do not remember the details.

I would not be surprised if the design decision for an empty blob was done without any deep thought or motivationg use case. After all, this was "I had nothing better to do, so wrote these out of boredom" patchset, as its cover letter said.

If somebody wants to carry these patches forward (which I am hoping because there were a few people who expressed interest recently, and because I am not all that interested, certainly not more than those who wanted to have this feature), I think that the right approach is to extend the system by taking advantage of the syntax that was designed to be extensible. In addition to ":(optional)", we could add different variants like ":(optional,ignore-empty)" with desired semantics, for example.

Thanks.