Tanay Abhra <tanay...@gmail.com> writes:

> If we take the easy way out, fixing UI mistakes would be easier,
> just replace git_config_cache() with git_config_raw() for such cases.

I do not think that would fly well.

The kind of "let's migrate funcname users to xfuncname while still
supporting the old uses" change will be done in the callback
functions like userdiff_config().  But it is very typical that
multiple config callback functions are cascaded (e.g. many
eventually end up calling git_default_core_config()); in order to a
workaround you suggest to help a callback in deep in a cascade chain
would require you to see which ones among all the callback functions
will eventually call the callback you are updating for migration and
update all git_config() calls to git_config_raw().

If you fix it properly (assuming it is feasible; I haven't heard if
you even tried to see how much work it would involve), you do not
need to introduce "git_config_cached()" (or "_raw()" for that
matter), which is a huge plus.  git_config() would instead do the
right thing automatically, giving the same semantics except that it
does not read the same file twice when it is known that the file has
not changed.

I can understand "If we take the easy way out, we do not have to do
much".  But it would not make it any easier---it essentially closes
the door for "oops, funcname is error-prone; let's give people
xfuncname" type of migration.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to