"Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> 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".
