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 = g...@github.com: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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
