On Wed, Feb 22, 2017 at 10:57 AM, Jeff King wrote:
> On Wed, Feb 22, 2017 at 09:36:12AM -0800, Junio C Hamano wrote:
>
>> >> My gut feeling is that we should do the selective/filtered include
>> >> Peff mentioned when a repository is known to be used as a submodule
>> >> of somebody else.
>> >
>>
On Wed, Feb 22, 2017 at 09:36:12AM -0800, Junio C Hamano wrote:
> >> My gut feeling is that we should do the selective/filtered include
> >> Peff mentioned when a repository is known to be used as a submodule
> >> of somebody else.
> >
> > Does the management of these submodue-related config value
Jon Loeliger writes:
> So, like, Junio C Hamano said:
>> Stefan Beller writes:
>>
>> > Do we want to invent a special value for url.*.insteadOf to mean
>> > "look up in superproject, so I don't have to keep
>> > a copy that may get stale" ?
>>
>> My gut feeling is that we should do the sel
So, like, Junio C Hamano said:
> Stefan Beller writes:
>
> > Do we want to invent a special value for url.*.insteadOf to mean
> > "look up in superproject, so I don't have to keep
> > a copy that may get stale" ?
>
> My gut feeling is that we should do the selective/filtered include
> Peff m
Stefan Beller writes:
>> This is true even without any submodules. The Git project itself
>> does not even care you are Stefan, but you still can and do add
>> [user] name = "Stefan Beller" to .git/config of your clone of the
>> Git project. A clone of the project may want to know more than the
On Tue, Feb 21, 2017 at 3:40 PM, Jeff King wrote:
>> > One other caveat: I'm not sure if we do insteadOf recursively, but it
>> > may be surprising to the child "git clone" that we've already applied
>> > the insteadOf rewriting (especially if the rules are coming from
>> > ~/.gitconfig and may b
On Tue, Feb 21, 2017 at 3:37 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Tue, Feb 21, 2017 at 3:00 PM, Jeff King wrote:
>> ...
>>> I guess one answer is that this is the wrong approach entirely, and the
>>> right one is something like: submodules should understand that they are
>>>
Junio C Hamano writes:
> So I would think it is entirely reasonable if "git submodule init
> sub" that is run in the superproject to initialize "sub" writes
> something in "sub/.git" to tell that "sub" is used in the context of
> that particular toplevel superproject and customize its behavour
>
On Tue, Feb 21, 2017 at 03:16:27PM -0800, Stefan Beller wrote:
> > I guess one answer is that this is the wrong approach entirely, and the
> > right one is something like: submodules should understand that they are
> > part of a superproject, and respect some whitelisted set of config from
> > the
Stefan Beller writes:
> On Tue, Feb 21, 2017 at 3:00 PM, Jeff King wrote:
> ...
>> I guess one answer is that this is the wrong approach entirely, and the
>> right one is something like: submodules should understand that they are
>> part of a superproject, and respect some whitelisted set of con
On Tue, Feb 21, 2017 at 3:00 PM, Jeff King wrote:
> On Tue, Feb 21, 2017 at 10:19:38AM -0800, Stefan Beller wrote:
>
>> On Mon, Feb 20, 2017 at 11:06 PM, Jeff King wrote:
>> >
>> > We'll see if the submodule folks have any ideas on how to implement
>> > that.
>> >
>>
>> So from reading your discu
On Tue, Feb 21, 2017 at 10:19:38AM -0800, Stefan Beller wrote:
> On Mon, Feb 20, 2017 at 11:06 PM, Jeff King wrote:
> >
> > We'll see if the submodule folks have any ideas on how to implement
> > that.
> >
>
> So from reading your discussion, the user expectation is to have
> `git submodule {ini
On Mon, Feb 20, 2017 at 11:06 PM, Jeff King wrote:
>
> We'll see if the submodule folks have any ideas on how to implement
> that.
>
So from reading your discussion, the user expectation is to have
`git submodule {init, update --init, sync}`
to pay attention to url..insteadOf when setting up the
On Tue, Feb 21, 2017 at 06:11:51AM +0100, Toolforger wrote:
> > I'm not sure I understand. You have a project policy to use certain
> > URLs. But you, the user, want to override that. Why isn't the
> > user-specific config file the right place to put that?
>
> Ah right, I mistook ~/ for "project
On 20.02.2017 21:52, Jeff King wrote:
> I think if there is a doc bug, it is that the repo boundary between the
> submodule and the super-project is not made more clear.
It's not mentioned anywhere I'm aware of, particularly not on the
insteadOf docs.
> That said, I do think it would be a usef
On Mon, Feb 20, 2017 at 09:31:40PM +0100, Toolforger wrote:
> > The submodule operations happen in their own processes, and do not look
> > at the config of the parent repo.
>
> Ah, then we have a docbug.
> git help config has this to say:
>
> url..insteadOf
> Any URL that starts with this v
On 20.02.2017 10:01, Jeff King wrote:
On Sun, Feb 19, 2017 at 10:12:28PM +0100, Toolforger wrote:
I am trying to make url..insteadOf work on the URLs inside
.gitmodules, but it won't work (applying it to the repo itself works fine,
to the config setting seems to be fine).
The submodule operat
On Sun, Feb 19, 2017 at 10:12:28PM +0100, Toolforger wrote:
> I am trying to make url..insteadOf work on the URLs inside
> .gitmodules, but it won't work (applying it to the repo itself works fine,
> to the config setting seems to be fine).
The submodule operations happen in their own processes,
Hi all,
I am trying to make url..insteadOf work on the URLs inside
.gitmodules, but it won't work (applying it to the repo itself works
fine, to the config setting seems to be fine).
I do not want to modify .gitmodules: It is maintained upstream.
I cannot simply reconfigure submodule..url: t
19 matches
Mail list logo
