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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 28, 2014, 20:00 UTC
Message-ID: <xmqqwqgft3bj.fsf@gitster.dls.corp.google.com>
In-Reply-To: <53108650.2020708@alum.mit.edu>

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

Show 6 quoted lines

> 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.