Re: Proposal: sharing .git/config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]