Re: RFC GSoC idea: new "git config" features

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> I just wrote up another double-idea that has been stewing in my head for
> a while:
>
> * Allow configuration values to be unset via a config file
> * Fix "git config --unset" to clean up detritus from sections that are
> left empty.

The former is *way* too large for a GSoC project.  Most
configuration variables are meant to be read sequencially and affect
in-core variables directly, like

        /* file-scope global */
	static int frotz = -1;  /* unset */

        static int parse_config_frotz(const char *key, const char *value, void *cb)
	{
        	if (!strcmp(key, "core.frotz"))
                	frotz = git_config_int(value);
		return 0;
	}

	... and somewhere ...
        	git_config(parse_config_frotz, NULL);

The config parsers are distributed and there is no single registry
that knows how in-core variables owned by each subsystem represent
an "unset" value.  In the above example, -1 is such a sentinel
value, but in some other contexts, the subsystem may choose to use
INT_MAX.  The only way to allow "resetting to previous" is to

 (1) come up with a way to pass "this key is being reset to
     'unspecified'" to existing git_config() callback functions
     (like parse_config_frotz() in the above illustration), which
     may or may not involve changing the function signature of the
     callbacks;

 (2) go through all the git_config() callback functions and make
     them understand the new "reset to 'unspecified'" convention.

which may not sound too bad at the first glance (especially, the
first one is almost trivial).

But the side effects these callbacks may cause are not limited to
setting a simple scaler variable (like 'frotz' in the illustration)
but would include things that are hard to undo once done
(e.g. calling a set-up function with a lot of side effects).

The latter, on the other hand, should be a change that is of a
fairly limited scope, and would be a good fit for a GSoC project
(incidentally, it has been one of the items on my leftover-bits list
http://git-blame.blogspot.com/p/leftover-bits.html for quite some
time).

Thanks.