Re: [PATCH v2 5/6] trailer: rename *_DEFAULT enums to *_UNSPECIFIED
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 14, 2023, 03:16 UTC
- Message-ID
- <xmqq1qf1la0q.fsf@gitster.g>
- In-Reply-To
- <owlyzg1pjx2f.fsf@fine.c.googlers.com>
Linus Arver <linusa@google.com> writes:
Show 20 quoted lines
>> It gets tempting to initialize a variable to the default and arrange >> the rest of the system so that the variable set to the default >> triggers the default activity. Such an obvious solution however >> cannot be used when (1) being left unspecified to use the default >> value and (2) explicitly set by the user to a value that happens to >> be the same as the default have to behave differently. I am not >> sure if that applies to the trailers system, though. >> >> Thanks. > > I get the feeling that you wrote the "Such an obvious ... differently" > sentence after writing the last sentence in that paragraph, because when > you say > > I am not > sure if that applies to the trailers system, though. > > I read the "that" (emphasis added) in there as referring to the solution > described in the first sentence, and not the conditions (1) and (2) you > enumerated. IOW, you are OK with this patch.
"that" refers to "the reason not to use such an obvious solution". I do not know if trailer subsystem wants to treat "left unspecified" and "set to the value that happens to be the same as the default" in a different way. If it does want to do so, then I do not see a strong reason not to use the "obvious solution".
Thanks.