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: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
