Jeff King wrote: > I don't think you can avoid the 3-step problem and retain the safety in > the general case. Forgetting implementation details for a minute, you > have either a 1-step system: > > 1. Fetch and start using config from the remote. > > which is subject to fetching and executing malicious config, or: > > 1. Fetch config from remote. > 2. Inspect it. > 3. Integrate it into the current config. I don't understand your emphasis on step 2. Isn't the configuration written by me? Why would it be malicious? I've just started thinking about how to design something that will allow us to share configuration elegantly [1]. Essentially, the metadata repository will consist of *.layout files, one for each repository to clone, containing the .git/config to write after cloning that repository. So, a git.layout might look like: [layout] directory = git [remote "origin"] url = git://github.com/git/git [remote "ram"] url = git@xxxxxxxxxx:artagnon/git [remote "junio"] url = git://github.com/gitster/git As you can see the [layout] is a special section which will tell our fetcher where to place the repository. Everything else is meant to be inserted into the repository's .git/config. However, I can foresee a problem in scaling: when I ask a specific directory like a/b/c to be populated (equivalent of repo sync `a/b/c`), it'll have to parse the layout.directory variable of all the .layout files, and this can be slow. So, maybe we should have a special _manifest.layout listing all the paths? Further, I see this as a way to work with projects that would otherwise require nested submodules like the Android project. What do you think? [1]: https://github.com/artagnon/src.layout -- 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