Re: [PATCH] Teach git submodule update to use distributed repositories

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2008, 09:00 UTC
Message-ID: <7vwsjj8t3s.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <m363r3y42v.fsf@localhost.localdomain>

Jakub Narebski <jnareb@gmail.com> writes:

Show 8 quoted lines

> "Nigel Magnay" <nigel.magnay@gmail.com> writes:
>
>> 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).
>> ...
> I _think_ that you can currently work around this problem by using
> URL rewriting (url.<base>.insteadOf).

Doesn't it also involve config modification?

I think the right thing to do for this kind of "trial merge" should be the same as cases that do not involve submodules. You *DO NOT* give a handy way to muck with your configuration to make "origin" point at fred. Instead, you would do something like:

	$ git fetch ../fred master
        $ git checkout FETCH_HEAD
        ... review test fix ...
	... when you are done, go back, discarding the state from Fred
        $ git checkout master

What submodule changes from the above workflow would be what happens after you switch to the trial state (the above example detaches HEAD temporarily while peeking into Fred's history). It is understandable that you would want to script something that recurses into the submodules that you have checked out (or submodules that Fred wants you to look at), do the equivalent of "git fetch ../fred" you did at the toplevel to automate that step, but I very much agree with Pasky here in that it feels very wrong to hijack "submodule update" for it.