Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]

> On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> 
> >> *move objects of submodules into base .git/ directory
> >> **This would, as I understand it: protect submodules from being
> >> overwritten and changes lost when switching between branches of the
> >> superproject that might or might not contain the submodules and
> >> centralize their management into one location.  The added benefits of
> >> fully using git's ability to branch and merge submodules makes it
> >> worth adding some complexity within the .git directory.
> >
> > The main problem with renaming/deleting is not the repository of the
> > submodule, but the working directoy.
> >
> 
> My understanding is that since the submodule objects (history) is
> stored in a .git directory in the subdirectory where the submodule is
> located, removing that subdirectory during checkout of a branch that
> does not include that submodule eliminates the .git directory as well.
> Moving the objects from the submodule's .git directory to the base
> .git directory would seem to alleviate this problem.

> >> *use .git instead of .gitmodules
> >> **I actually don't know why this was included with the project
> >> description, I searched for an explanation of the desired name change
> >> on the mailing list and in commit messages, but came up with nothing.
> >
> > AFAICT somebody thought that the information about the locations of the
> > submodules should be in .git/ rather than in the working directory.  But
> > of course, that is wrong: you want it to be tracked.
> 
> So, in looking back through the archives of the mailing list there
> seems to be some disagreement between using .gitmodules and
> .git/config to track submodules.

> >> *git submodule update --init should initialize nested levels of submodules
> >> **As an ease of use command, either an additional flag to recurse can
> >> be added, or it can act by default. As a requested feature on the
> >> mailing list, this is worth implementing.
> >
> > I thought there was a patch to support "git submodule recurse"?  That
> > would be rather less limited than yet another option to submodule update.
> 
> There is a git submodule foreach command, but it doesn't look like the
> patch for git submodule recurse
> (http://marc.info/?l=git&m=120997867213008&w=2) has been incorporated
> into a public release.
> 
> That is one route, on the other hand, the default action is also open
> to question. When I update a submodule, I would probably expect that
> anything it depends on is also updated. The default action probably
> should be recursive.

> >> *ability to update submodule pulled from svn repo
> >> **One workaround is to clone it as local copy using git-svn and then
> >> import that local clone as a submodule; clearly a clunky solution.
> >> There are many requests for this feature (see
> >> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
> >> for a typical example), and it makes sense integrating git-submodule
> >> with git-svn would expand submodule's usefulness.
> >
> > I do not think that this would be good.  Both "git svn" and "git
> > submodule" are rather complex by now, and mixing them would only
> > complicate code.
> 
> Hm, point well taken, but it would seem to have enormous benefit for a
> lot of people. I can move it down the priority list, but I'd like to
> include it in the proposal - complexity alone isn't a good reason to
> avoid something.