Jeff King wrote: > On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote: > >> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra >> <artagnon@xxxxxxxxx> wrote: >> > 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? -- 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