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

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:

On 3/30/09, Shawn O. Pearce [off-list ref] wrote:

quoted

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.

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

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

quoted

 Further, you spend roughly a month writing method stubs.

Week max: end of May to beginning of June, but if I

... yes?

Ciao,
Dscho