Re: Proposal: sharing .git/config

Jeff King wrote:

On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:

quoted

On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
[off-list ref] wrote:

quoted

Hi,

I have this itch where I want to share my remotes config between
machines.  In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.  There
are also other things in .git/config that would be nice to share, like
whether to do a --word-diff (why isn't it a configuration variable
yet?) on the repository.  The only problem is that I have no clue how
to implement this: I'm currently thinking a special remote ref?

If you check out the config file, then include.path should work. You
could add include.ref to point to a ref, but you need to deal with the
attached security implications. This has been proposed before (and
turned down, I think).

Here's the patch:

  http://article.gmane.org/gmane.comp.version-control.git/189144

The basic argument against it is that you would _not_ want to do:

  $ git config include.ref origin/config

because it's unsafe (you immediately start using config fetched from the
remote, before you even get a chance to inspect it). So the recommended
way to use it is:

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

  [time passes...]

  $ git fetch
  $ git diff config origin/config ;# inspect changes
  $ git update-ref refs/config origin/config

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?