Re: [PATCH 5/5] config: add default aliases

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 2, 2021, 15:39 UTC
Message-ID: <xmqqr1ggpvxc.fsf@gitster.g>
In-Reply-To: <03a401d76f45$e1c6fce0$a554f6a0$@nexbridge.com>

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> I am sorry if I am coming across too strongly on this subject, but
> I do think we are overloading alias capability and intruding on a
> domain that should be reserved for our users, not ourselves.

Well said. The customization feature is for helping users, and we shouldn't get in their way by adding unnecessary ones ourselves.

I wouldn't recommend us to force to our users even "co is for checkout" that everybody seems to have. Adopting such a customization or not should be up to the users, and we should not get in the way of other users who may want to say "co for me is commit".

One thing that might (or might not) help to help users and projects share the same set of aliases is to make it easier to audit shared configuration file before inclusion. I wonder if would help to introduce "include.allow" and "include.block" configuration variables

    [include] ;; or [includeIf "<condition>"]
	path = /usr/share/git/contrib/svnlike.alias
	allow = alias.*

that tells us to only pay attention to the configuration keys that match these 'allow' patterns when reading from the given path.

But in practice, 'alias' is one of the riskier things you can set in the configuration file, so it is of dubious value to say "with this allow-list feature, you do not have to worry about random cruft defined in the included path---you only need to concentrate on auditing alias.* configuration items in there and nothing else".