The basic idea is that the server could advertise some config options which it recommends the client sets for a given repo after a fetch. Some possible use-cases for this feature include setting: - format.subjectPrefix to 'PATCH my-project' - sendemail.to to the mailing list address - push.pushOption to recommended push options Upon cloning, each recommended config option would be displayed to the user, and they would be prompted ([Y/n]) to agree to set that value in the config file for that repository. Additionally, there would be a config option which white-lists a list of config options which are automatically agreed to without prompting, and each config option would have one of the following states: - accept-silent: set the option without printing a message - accept-verbose: set the option and display a message - prompt: prompt the user to set this config option - reject-silent: silently refuse to set this config option - reject-verbose: refuse to set this config option and display a message We would default to reject-verbose for all unknown config options and include a set of defaults which specifies the appropriate trust level for various useful benign options (such as the examples above). The implementation would involve advertising config-advertisement in the fetch protocol. Both the client and server would have to agree to use it. If the server supports it but the client does not (in the case of an old client), it could fall back to printing the list of recommended options to stderr. To choose which config options to advertise, a new option would be introduced (uploadpack.advertiseOptions) for example, which has a list of .git/config options from the remote repository to forward to the client. This would be a lot of work so I'd like to float it for discussion before getting started. What do you guys think?
