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

2 messages, 2 authors, 2021-07-02 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2021-07-02 15:39:17

"Randall S. Becker" [off-list ref] 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".

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

From: Felipe Contreras <hidden>
Date: 2021-07-02 20:41:40

Junio C Hamano wrote:
"Randall S. Becker" [off-list ref] writes:
quoted
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.
Nobody is getting in their way, and if they are unnecessary why does
*everyone* have aliases?
I wouldn't recommend us to force to our users even "co is for
checkout" that everybody seems to have.
They are not being forced.
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.
contrib is a black whole where nothing comes out of, so I would rather
not doom yet another useful feature to that fate.
But in practice, 'alias' is one of the riskier things you can set in
the configuration file,
Why?

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help