Re: Alternative approach to the git config NULL value checking patches..

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Linus Torvalds <torvalds@...>
Cc: Git Mailing List <git@...>
Date: Sunday, February 10, 2008 - 6:29 pm

Linus Torvalds <torvalds@linux-foundation.org> writes:


Exactly.  My answer to your question is: "It is not different
from checking against NULL at all."

The first one (i.e. you needed to do so in your patch) shows
that the codepath that is already doing the right thing needs to
be modified.  If we do not introduce config_true, we do not even
have to.  You need additional change to correctly functioning
codepaths that you should not have to do.

The second one shows that even if we introduce config_true, such
an already broken codepath needs to be fixed to check with
either NULL or config_true anyway.  The need for fix the
codepath has not been reduced.  Changing the rule does not help
for this class of codepath.

But as you seem to imply, it might make sense to equate

	[some-random-section]
        	some-random-variable

to

	[some-random-section]
        	some-random-variable = ""

for variables that cannot possibly have any meaningful "bool"
semantics.  This third class of variables is a possible benefit
your patch brings in.  The code can be lax for these variables.

However, it would make things inconsistent ("this variable is
bool and the above two forms mean completely opposite things,
while that variable is not bool and they mean the same thing").
I am just having a hard time convincing myself that this little
detail does not matter.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: Alternative approach to the git config NULL value checki..., Junio C Hamano, (Sun Feb 10, 6:29 pm)