Re: Auto update submodules after merge and reset

From: Jens Lehmann <jens.lehmann@web.de>
Date: Nov 30, 2011, 08:31 UTC
Message-ID: <4ED5E9D2.4060503@web.de>
In-Reply-To: <4ED57EED.4040705@qualcomm.com>

Am 30.11.2011 01:55, schrieb Max Krasnyansky:

> Does anyone have a pointer to a thread/discussion that explains why git submodules are not auto
> updated when the superproject is updated (merge, reset, etc) by default?

This is because in current git a submodules work tree gets only updated when running "git submodule update". A default auto update wouldn't be backwards compatible (and some users really like it the way it is now). I'm working on a patch series to teach Git to optionally update the submodules work trees on checkout, reset merge and so on, but I'm not there yet.

> Assuming a simple and default setup where submodule update policy is set to "checkout".
> It seems that the default and sane behavior should be to update (checkout) corresponding submodule
> commit to track the superproject.

I agree, but we should decide about a sane default when the feature is there. In the first version it will be off by default, so people can make up their minds about breaking backwards compatibility.

> I can't seem to find convincing explanation why it's not the case :). Having to manually update
> submodules after pull or reset has been error prone and confusing for the devs I work with.

Yes, we even had some mis-merges because of that.

> I'm thinking about adding a config option that would enable automatic submodule update but wanted
> to see if there is some fundamental reason why it would not be accepted.

I think adding something like an "submodule.autoupdate" config makes lots of sense, but IMO it should affect all work tree updating porcelain commands, not just merge.