Hi, On Mon, 25 May 2009, Avery Pennarun wrote: > On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > Because in the project I use submodules most heavily, there is one > > recurring theme: you cannot push to the submodules. And by "you" I mean > > "a regular user". > > > > So virtually all you do in these submodules cannot be pushed at all. It > > has to be submitted to the respective submodule maintainer. > > > > And guess what happens in such a case when you set that tentative "update" > > variable to "merge"? > > > > Exactly. > > > > FWIW I consider any scenario where the average users have push access to > > the submodule a toy scenario. > > I have the same problem. Out of curiosity, how do you handle the case > where you really need to make a change to the submodule and let your > team members see that change, even though the submodule's upstream is > slow and/or doesn't accept the patch? > > In that situation, we've had to make local shared mirrors of all the > submodules and point .gitmodules at that. But that would be your > "toy" scenario - our local users have push access to the submodule. Happily enough, our changes were accepted so far. For a few branches, though, the patches are not ready to be sent upstream (or, from a certain viewpoint, sometimes downstream) yet, so we do have local forks for those working on that. Note, however, that even in this case, it is better to use 'rebase' rather than 'merge', for exactly the same (I almost wrote "unconvincing") reason as before. Ciao, Dscho P.S.: in some cases, the submodules' "upstreams" are maintained by team members, but that is very much on purpose. They are trusted maintainers, and there is no reason to let some young and maybe overly energetic friends push to such a trusted repository.