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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 31, 2009, 15:57 UTC
Message-ID: <alpine.DEB.1.00.0903311749160.7052@intel-tinevez-2-302>
In-Reply-To: <526944450903310830q5f56fe82xb64ae8dc3c954ffb@mail.gmail.com>

Hi,

I am a rather intense user of submodules, so I am quite interested.

Please take my comments as encouragement rather than discouragement.

On Tue, 31 Mar 2009, P Baker wrote:

Show 13 quoted lines

> On 3/30/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> > IMHO, this is too vague.  *What exactly* are the features you want to 
> > add to git submodule?  Break this down by features, not by phases of 
> > coding.
> 
> The features I have been considering are:
> *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.

> *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.

> *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.

Show 7 quoted lines

> *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.

Show 5 quoted lines

> *make submodules deal with updated references
> **Instead of issuing merge conflicts on updated submodule references,
> this will allow submodules on default detached HEAD so that changes
> from the local repo can be committed without first pulling changes
> from the shared repo.

I'd rather call this "make git-submodule help with merging".

> *protect changes in local submodules when doing “git submodule update”
> **This is similar to the previous point, in that changes need to be
> protected or merged or warnings issued when updating the submodule.
> The potential to lose work with no warning is a big no-no.

One word: Reflogs.

> *make git submodules easy to remove
> ** See http://pitupepito.homelinux.org/?p=24, for an example of why
> this is a pain. Adding a submodule has ui, removing one should as
> well.

AFAIR there was already a patch to implement this, but the OP apparently did not address all issues.

> >  Further, you spend roughly a month writing method stubs.
> 
> Week max: end of May to beginning of June, but if I

... yes?

Ciao, Dscho