Re: git submodule update --merge

Hi,

On Mon, 25 May 2009, Avery Pennarun wrote:

On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

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.