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 <spearce@xxxxxxxxxxx> 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. > *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. > > Further, you spend roughly a month writing method stubs. > > Week max: end of May to beginning of June, but if I ... yes? Ciao, Dscho
