Thanks for the comments, my replies are included. It's good to see some core folks are big users! On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > I am a rather intense user of submodules, so I am quite interested. > I'm curious, where/under what circumstances do you tend to use it? > Please take my comments as encouragement rather than discouragement. > Always. >> *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. I also believe that the workaround described, if incorporated into git-submodules.sh in an appropriate way might open up possibilities for further improvement. The UI would change much, seems like it'd just be detection of pointing to a SVN repo instead of a git repo and then hooking into git svn calls instead of regular git calls. This brings up the possibility that git submodules should abstract its repository handling in much the same way that git does. I'm not familiar with the code, but this seems more like calling other plumbing hooks than anything else. >> *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". > Better name. Duly noted. Will change. >> *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. > I haven't used reflogs, but it doesn't seem to fix the problem (maybe you can explain?): simply knowing where/what the reference is, doesn't mean that git-submodule looks at it, obeys the reference or issues warnings when it should. The problem as stated (http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1211380200000#c3897235118548537475) was that git submodule update would silently overwrite any local changes with the remote version (i.e. git did not check to see if the local reference was different than the remote reference when updating). >> *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. > Yep, found it on the mailing list. Obviously, part of the project would be to resolve those final issues. Phillip Baker -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
