Re: Proposal: sharing .git/config

On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote:

quoted

But it was pointed out that you could also just do:

  $ git config include.ref upstream-config
  $ git show origin/config ;# make sure it looks reasonable
  $ git show origin/config >.git/upstream-config

and so forth. There are some ways that a pure ref can be more
convenient (e.g., if you are carrying local changes on top of the
upstream config and want to merge), but ultimately, you can replicate
any include.ref workflow with include.path by adding a "deploy" step
where you copy the file into $GIT_DIR.

This seems to be unnecessarily complex and inelegant.  Maybe this
functionality is best managed as a separate git repository: `repo`
from depot_tools uses a manifest repository containing all the project
metadata.  Maybe we can extend it/ write an more general version?

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.

We can automate the sequence to remove as much friction as possible, but
fundamentally step 2 requires some effort from the user.  Moving the
config to a separate repo does not get rid of those steps.  The user
either does not look at the config before using it, in which case we are
no better than the 1-step scenario, or they do, in which case they are
replicating the 3-step scenario.

The other alternative is to automate step 2. The simplest way would be
to have a whitelist of "ok to share" config, that would not include
things like diff.external that can run arbitrary code. I don't know
whether that would make the system too limited for what people want to
do. Do we have a concrete example of what config people would like to
share in this manner?

-Peff