From: Jakub Narebski <jnareb@gmail.com>
Date: Fri, 18 Jul 2008 08:45:23 GMT
Subject: Re: [PATCH] Teach git submodule update to use distributed repositories
Message-ID: <m363r3y42v.fsf@localhost.localdomain>
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>

"Nigel Magnay" <nigel.magnay@gmail.com> writes:

> On Thu, Jul 17, 2008 at 7:22 PM, Petr Baudis <pasky@suse.cz> wrote:
>> On Thu, Jul 17, 2008 at 04:07:11PM +0100, Nigel Magnay wrote:
>>> And it works, but
>>>
>>> $ git pull fred
>>> $ git submodule update
>>>
>>> Can leave you with problems, because if a submodule wasn't pushed to
>>> origin, you won't have it available. This is because the commands are
>>> equivalent to
>>>
>>> $ git pull fred
>>> for each submodule()
>>>   cd submodule
>>>   git fetch origin
>>>   git checkout <sha1>

> "Someone says 'please review the state of my tree, _before_ I push it
> out to a (central) repository"
> 
> Fred is a person (and != origin). His tree(s) are entirely correct and
> consistent, and he doesn't yet wish to push to origin (and perhaps he
> cannot, because he does not have permission to do so).
> 
> All the tutorials give credit to the fact that in git you don't need a
> central server - you can pull directly from people. Except in the case
> where you're using submodules, where you're basically forced to
> hand-modify .git/config (in this instance, to point to where 'fred' is
> storing his submodule trees) before doing a submodule update. This
> makes git complicated for users.
> 
> I'm trying to improve the UI for projects using submodules to make it
> mostly transparent; the best way I can come up with is to pick on
> individual usecases and show that they're a particular pain and that
> perhaps they don't need to be.

I _think_ that you can currently work around this problem by using
URL rewriting (url.<base>.insteadOf).

-- 
Jakub Narebski
Poland
ShadeHawk on #git