Remote "push" syntax

From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:43:06

I'm splitting the code for reading configuration of remotes out of 
builtin-push, for eventual use by builtin versions of additional commands, 
as well as to make git-push hopefully a bit nicer to use, so I'm wodnering 
about details of the behavior I should match.

Is it actually valid to have wildcards in the "push" configuration for a 
remote? git-push seems to skip them when looking at configuration files, 
and the documentation only talks about them being valid on the command 
line. Is there some reason to filter them out of the configurations, 
rather than just treating them as (unlikely) literals?

git-push currently always defaults to "origin", even if there is a 
different remote configured for the current branch. It seems to me like 
using the branch's remote would be better if there is one.

Do we care about the order of precedence of ways of configurating remotes? 
The current order is remotes > config > branches; it would be convenient 
to use config > remotes > branches, particularly because I'd like to read 
the config file first to find out the branch configuration.

	-Daniel
*This .sig left intentionally blank*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help