Re: [PATCH] Teach remote machinery about remotes.default config variable

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Jan 15, 2008, 23:08 UTC
Message-ID: <478D3CD8.3040805@gmail.com>
In-Reply-To: <7vy7arhas9.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 17 quoted lines

>> Nope, git submodule *still* requires origin (e.g., execute git
>> submodule init or update on a detached head).
>>     
>
> Now I am even more confused.
>
> The approach I suggested in a few paragraphs above, to which you
> just said "I like this change", is about making "git submodule
> update" to use the url configured in the upper level repository
> when it runs "git fetch".  I am looking at around l.238 of
> git-submodule.sh.  In the current code, it runs "git-fetch"
> without any parameter, which would allow it default to origin or
> whatever, which may or may not be desirable depending on where
> the 'origin' points at.  If you make that particular git-fetch
> explicitly say where the fetch should be done from, wouldn't it
> fix the issue for that codepath?  Why does it still require
> origin?

1) If top-level is on a detached head, then the remotes machinery will 
find current remote is "origin". This is what would be passed down the 
chain.

2) Absent the other changes in the thread, git-submodule-init still 
invokes   git clone *without* -o in the submodules, and thus still 
defines and points to remote "origin".

Mark