Submodules and merge conflicts

Henk· May 21, 2009, 13:22 UTC · lore

We have a git repository with 2 submodules structured like this:
-Root
 -Src
    -Scripts [Submodule]
    -Kernel [Submodule]
    -Web

When someone makes changes in the Kernel submodule, the sha1 of the submodule changes. This means that the repository that uses this submodule also changes because the link to the submodule changes. This very often causes confusion. Co-workers very often get merge-conflicts on the submodule sha1 which are annoying and confusing.

The reason we like using submodules instead of having one larger repository is that there are seperate teams working on each module. We also use other version numbers voor the kernel and the appllications using the kernel.

Instead of using the sha1 of a specific revision in the submodule, I would find it more logical to use a branch-name or tag. This way you can commit on the submodule without having to commit the new submodule revision to the main repository also.

I would like to hear your thoughts on this. Maybe we are using submodules wrong, or maybe this is already possible.

Henk Westhuis

-- 
View this message in context: http://n2.nabble.com/Submodules-and-merge-conflicts-tp2951928p2951928.html
Sent from the git mailing list archive at Nabble.com.

Avery Pennarun· May 21, 2009, 20:31 UTC · re: Henk · lore

Re: Submodules and merge conflicts

On Thu, May 21, 2009 at 9:22 AM, Henk <henk_westhuis@hotmail.com> wrote:

Show 7 quoted lines

> Instead of using the sha1 of a specific revision in the submodule, I would
> find it more logical to use a branch-name or tag. This way you can commit on
> the submodule without having to commit the new submodule revision to the
> main repository also.
>
> I would like to hear your thoughts on this. Maybe we are using submodules
> wrong, or maybe this is already possible.

The primary advantage of the git submodule code is the ability to lock to a specific sha1. If you don't want to do that, you're not going to get much benefit from using submodules.

One option here is to simply skip the 'git submodule' altogether and just have a script that checks out the other git repositories into subdirs. Then you have total control over which branches, etc are included, the changes to the script (eg. to change which branch you want to use) can be merged just like changes to anything else.

We do something in between on our internal projects: we use git submodules to lock in the sha-1 (it's really valuable to know *exactly* which version of everything was used in a particular release), but we have scripts to auto-update the sha-1 for each submodule to the tip of the right branches.

For some other projects, we also use the git-subtree tool I developed (http://alumnit.ca/~apenwarr/log/?m=200904#30) but given that your submodules are huge things like the Linux kernel, it's probably not appropriate in your case. You might want to look at it anyway in case I'm wrong.

Have fun,

Avery