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
>> <> 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:
> 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
More majordomo info at

Reply via email to