Re: Proposal: sharing .git/config

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 18, 2013, 09:00 UTC
Message-ID: <CALkWK0nWXCO_EXfx69m8XbrFe=ABBodPdFbSrS9v3VqgfbnQ+w@mail.gmail.com>
In-Reply-To: <20130312085342.GA11340@sigill.intra.peff.net>

Jeff King wrote:

Show 11 quoted lines

> 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@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