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* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html