Re: git submodule update --merge

From: Johan Herland <johan@herland.net>
Date: May 25, 2009, 22:48 UTC
Message-ID: <200905260048.54625.johan@herland.net>
In-Reply-To: <alpine.DEB.1.00.0905252149370.4288@intel-tinevez-2-302>

On Monday 25 May 2009, Johannes Schindelin wrote:

Show 16 quoted lines

> On Mon, 25 May 2009, Avery Pennarun wrote:
> > On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin 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.

Well, in the scenario I described earlier, the project developers (your "average users") _do_ have push access to the submodules. And that scenario is certainly not a toy scenario.

Show 8 quoted lines

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

For the purposes of this discussion, this is pretty close to the use case I described earlier in my scenario as well. Thanks, Avery, for presenting the argument in a more readable manner.

Show 9 quoted lines

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

Yes, and I have never argued that your "average users" should use 'merge'. Indeed I have not argued that 'merge' is suitable for your workflow _at_ _all_.

One of the guiding principles I have learned from earlier submodule discussions on this list, is that the git submodule commands should NOT impose restrictions on the workflows available to its users. But in this case you are using your own workflow to argue what should, and should not be part of the git submodule repertoire. I am arguing that there are _different_ workflows, with _different_ requirements where 'merge' would be a useful addition. Just because you won't ever use it, does not mean that it will not be useful to anybody else.

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

Do you argue that protecting these "young and maybe overly energetic" developers from themselves should be hardcoded into the git submodule behaviour, in such a way that it obscures the availability of other alternative submodule workflows?

Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net