"Drew DeVault" <sir@xxxxxxxxx> writes: > 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? Assuming I am among the guys (do you solicit opinions from gals, by the way?), here are a few unconnected random thoughts. I do not want to see this as a "server" thing. All the examples are "per project preference" and I do agree it would be nice to have a standardised way for projects to communicate their preference to their participants. Regardless of the hosting site I clone and fetch my project from, I'd want to see it communicated consistently to them. Which means that it must not be a patch to the "server" component to what responds to your "git fetch" and "git clone" (i.e. upload-pack) as some hosting sites do not even use upload-pack. Also, I do not want to see this as a "git" thing and I mean it in two ways. In addition to your examples of "per project preference", there are projects' coding style guides, etc., that we do not enforce as git config at all, e.g. how wide your editors TAB and single level of indentation should be. It will unnecessarily narrow your view to assume that the kind of "per project preference" you convey from the project to its participants need to be the Git configuration and nothing else. And this should not be a "git the SCM" thing. If you download and extract a release tarball and write a patch on top of it, you should be able to learn what the project convention of what the "[PATCH]" prefix looks like and what the mailing list address is, even though you did not clone with "git". All of the above leads to a design to have a common convention widely shared among projects to express project preferences over different kind of tools, among which Git is one of them, and store it in a known location in the projects' trees. Most importantly, there must not be any Git protocol extension for doing this kind of thing. Don't limit the user's choice in either of these two ways. The preferences for tools other than Git should be sharable with the same ease as preference for Git, and the preference should be sharable with the same ease to those who use Git and those who don't. Perhaps have a .project-preference/ directory at the root level of the project tree, talk with other SCM vendors and editor vendors to design what kind of information are recorded in that directory and how, and write a script to work on that to map the project preference information to git configuration while other SCM vendors and editor vendors write their scripts to help their users to map the project preference information to the configuration files that their tools use. Then you can either write a wrapper around "git clone" to first run "git clone" and then run these scripts you prepare to process the contents of the .project-preference directory, or perhaps trigger these scripts from the post-clone hook.
