threads / discuss / 11171

After-the-fact submodule detection or creation

Subject: After-the-fact submodule detection or creation

## tl;dr

3 messages between Dec 7, 2007 and Dec 7, 2007.

replies: 2people: 2as markdown or json

Michael Poole· Dec 7, 2007, 03:01 UTC · lore

I have a project where most branches have one subdirectory for the core program and other subdirectories for support scripts, programs and libraries. The supporting subdirectories vary from branch to branch. However, some branches contain just the core program, with no subdirectories. Starting from scratch, I would say the core program should be a submodule, but historically it was not populated as one.

Is there a way to easily create such a pseudo-submodule branch in git, or are real submodules strongly preferred for this kind of scenario?

(The added twist: I ran into this while importing a Subversion repository. git-svn identified two trees of history in the repository -- one history containing the core plus support trees, one history containing just the core program. Since the trees do have the same contents, only the commits are duplicated, but that is not quite ideal.

It seems like using the current submodule code would mean that this kind of import would need two passes over the foreign repository, rather than one if the branch could be created after the parent tree is initially imported. I can live with that -- it is a rather unusual case -- but maybe there is a better way.)

Michael Poole
Alex Riesen· Dec 7, 2007, 07:37 UTC · re: Michael Poole · lore

Re: After-the-fact submodule detection or creation

Michael Poole, Fri, Dec 07, 2007 04:01:04 +0100:
Show 5 quoted lines
> It seems like using the current submodule code would mean that this
> kind of import would need two passes over the foreign repository,
> rather than one if the branch could be created after the parent tree
> is initially imported.  I can live with that -- it is a rather unusual
> case -- but maybe there is a better way.)

Import the core module in a branch all by itself, and merge it in every support branch?

    Supp1: o-o-o-----o-o-o-o-o-o-o
		    /
    Core:  o-o-o-o-o
		    \
    Supp2: o-o-------o-o-o-o
Michael Poole· Dec 7, 2007, 21:35 UTC · re: Alex Riesen · lore

Re: After-the-fact submodule detection or creation

Alex Riesen writes:
Show 16 quoted lines
> Michael Poole, Fri, Dec 07, 2007 04:01:04 +0100:
>> It seems like using the current submodule code would mean that this
>> kind of import would need two passes over the foreign repository,
>> rather than one if the branch could be created after the parent tree
>> is initially imported.  I can live with that -- it is a rather unusual
>> case -- but maybe there is a better way.)
>
> Import the core module in a branch all by itself, and merge it in
> every support branch?
>
>
>     Supp1: o-o-o-----o-o-o-o-o-o-o
> 		    /
>     Core:  o-o-o-o-o
> 		    \
>     Supp2: o-o-------o-o-o-o

Yes, that's the obvious way to do it with submodules. Teaching git-svn to use that is the hard part.

Since the core code was first branched independently at r734 in the existing repository, the import (either automated or manual) would need to go through once to identify what subdirectories are actually submodules in git terminology, and make a second pass to actually perform the imports. If the submodule creation could happen after the fact, it would only need one pass.

Maybe the right question to ask is whether having a partial-tree branch can be reasonably handled by git (in particular, detecting a rename of the core subtree to the top-level tree in the new branch's first commit). If git understand that operation, then what I would like to do would be reasonably straightforward. If it does not make sense, then I'll think about how to teach git-svn that certain subdirectories should be promoted to submodules.

Michael Poole

← back to recent threads