Re: FW: Query on git submodules

From: Mattias Vannergård <mattias.vannergard@gmail.com>
Date: Jun 2, 2015, 09:45 UTC
Message-ID: <loom.20150602T113612-540@post.gmane.org>
In-Reply-To: <4C328B7D13677A4EAF715D0755A6D7EE25C5AD9E@irsmsx110.ger.corp.intel.com>

Frawley, Sarah <sarah.frawley <at> intel.com> writes:

> Correct when I referred to 10+ layers I meant nested repositories

which make up a large hierarchy.  Some

> repositories are repeated across the hierarchy.  We check-out

submodules to tag versions (as opposed

> to master branch).  If we need to roll out a particular change across

a hierarchy (e.g. 60 repos) then

Show 5 quoted lines

> every level in the hierarchy needs to pick up new submodule tags.
> 
> The main 2 issues that we see are:
> 
> 1. Enforcement of absolute paths in git submodules - I am currently

trialing using a pre-commit hook to

> highlight this issue to users so that they can fix their submodule

urls to relative paths.

We enforced the config file instead (containing the host, port and username) because we use Gerrit. So, our urls are just ssh:\\<server>:<repo>

> 2. Slowness Integrating updates to submodule hierarchy -I have been

looking at ways of automating such a

> roll out - this can be useful for new project setups or for rolling

out an update to all repos and quickly

> integrating it into the submodule hierarchy.  The link below shows

something similar however it checks

> out a master branch of each submodule in its hierarchy.

https://chrisjean.com/recursively-updating-git-submodules/

I haven't been able to check performance at our site yet.

> Thanks,
> Sarah

I am planning on using submodules in a way, where I can specify a configuration of repos with tags, and rebuild the submodule tree, when selecting a configuration on the top level.

But, yet I have found no easy way to select the tag in a subrepo. I would like the .gitmodules to accept tag instead of branch. I think there is very little difference between specifying a branch or a tag, but it is more convenient to have the release version as a tag.

So, if a product A, consist of subcomponents a1, a2 and a3, the version v1.1 of product A will have a configuration saying: a1, tag=v0.4; a2, tag=v1.0; a3, tag=v2.0

Subcomponent can be both a pre-built binary or a shared/common source base, or a complete 3rd party repository.

Is this comparable to your situation?

I am currently working on editing the git-submodules to add -t (as in tag). I need to find an easy way to switch between tracking a branch and locking to tag, though.

BR /Mattias