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

From: Petr Baudis <pasky@suse.cz>
Date: Jul 18, 2008, 09:16 UTC
Message-ID: <20080718091608.GL10151@machine.or.cz>
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>

Hi,

  _please_, trim the parts of quoted e-mails that you are not reacting
to. It makes your mails easier to read.

On Fri, Jul 18, 2008 at 09:11:53AM +0100, Nigel Magnay wrote:

Show 14 quoted lines

> No.
> "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.

Ok! Handling this case makes sense, though I would have wished you to word this use case this clearly from the beginning; or maybe I'm just slow. :-)

Now, we (at least we two) agree that this use case is worth supporting, I still don't like the solution you propose, though. The problem that we are trying to solve is:

	"How do we mass-supply custom submodule URLs when publishing the
	customized main repository at a custom location too?"

Now, the most natural solution is for Fred to actually customize .gitmodules content when committing the submodule updates:

  (i) Either just give submodule update a hypothetical flag that will
ignore .git/config for that particular run or,

  (ii) even much better, actually change logical submodule names in
.gitmodules; this is appropriate as you want the modules to actually
point at a significantly different repository. Thus,

	[submodule "boo"]
	path=boo
	url=git://repo.or.cz/boo.git

will become

	[submodule "boo/fred"]
	path=boo
	url=git://repo.or.cz/boo/fred.git

  Also, you will be able to redefine the URL of boo/fred too in
.git/config (e.g. you're behind a firewall that lets only HTTP
through; I'm actually behind such a firewall these days at my
(non-SUSE ;) work).

This should be reasonably elegant, works with no Git changes, however still has one significant problem - you very much do not want such a .gitmodules change in any of the commits you merge, since it breaks bisectability in case Fred or his repositories go away.

In that case, several possibilities come up on my mind:

  (1) Fred will prepare special branch for testing with modified
.gitmodules and then for a merge he offers a different branch with clean
.gitmodules. This works, but it is obnoxious.

  (2) Fred will pass a patch for .gitmodules as a part of his review
request. This works too and is obnoxious in slightly different aspects
than (1).

  (3) Fred will offer a rewrite rule that you will pass to submodule
update, like your solution proposed, but much more universal so that it
is not tailored just to your particular repository hierarchy. A simple
sed script could work fine.

  (4) Something else that I'm not realizing.

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce