Re: Auto update submodules after merge and reset

["Andreas T.Auer" <andreas.t.auer_gtml_37453@ursus.ath.cx>]

Jens Lehmann wrote:

> Am 30.11.2011 01:55, schrieb Max Krasnyansky:
> 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.
>
>> 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.
Because there is no good way to do so. It would be fine when you just track 
the submodules "read-only", but if you are actually working on submodules, 
it is a bad idea to always get a detached HEAD. It is also a bad idea to 
merge or rebase on the currently checkedout branch. Because if you are 
working on a maint branch in the submodule and then you checkout a pu branch 
in the superproject, because you have forgotten that maint branch in the 
submodule then all the proposed updates go to the maintenance branch -> bad. 
So auto-update is not easy. But below I describe an idea that might solve 
these issues and help auto-udpate to work in a sane way.
 
> 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.

I was thinking about submodule integration and had the idea to bind a 
submodule to the superproject by having special references in the submodule 
like refs/super/master, refs/super/featureX... So these references are like 
tracking branches for the refs/heads/* of the superproject.

If you have tracking branches, the supermodule can just update the 
corresponding branch. If this branch is currently checkedout and the work 
area is clean, then the work area is updated, too. If there is currently a 
local branch or a diffent super-branch checked out then the working area 
should be considered "detached" from the superproject and not updated. 

With this concept you could even switch branches in the superproject and the 
attached submodules follow - still having no detached HEAD. When you want to 
do some local work on the submodule you checkout a local branch and merge 
back into the super branch later. The head of that super branch might have 
changed by the update procedure meanwhile, but that is fine, then you just 
have a merge instead of a fast-forward.

Another nice feature would be a recursive commit. So all changed index files 
in the _attached_ submodules would first be committed in their submodules 
and then the superproject commits too - all with one command. Currently it 
feels a little bit like CVS - commit one file(submodule), commit the other 
file(submodule) and then apply a label(commit the superproject) to keep the 
changes together. 

If the submodule is not attached the commit in the superproject can still 
detect changes that have been made to the corresponding tracking branch and 
pick these up.

As a summary: Tracking submodule branches in the superproject instead of 
only the current HEAD of the submodule gives you more freedom to install 
sane auto-update procedures. Even though it will raise a lot of detailed 
questions like "should the refs/super/* be pushed/pulled when syncing the 
submodule repositories".