I'll paraphrase to see if I understand your points: *Moving objects from submodule .git directories into the base .git/ directory would protect the submodules and is a good idea. *Moving to a .git/ file from .gitmodules should be taken off of the goal list (I went back and read this thread: http://thread.gmane.org/gmane.comp.version-control.git/78605; seemed to clear things up). *git submodule recurse would be a good option (not as a default), if the remaining issues are resolved. *It would be a good idea for git submodule to work with foreign VCS, through Daniel's patches. I appreciate the guidance, it's helping me to see that some of this work has already been done, it needs to be finished and pushed into a public release. As an intense user of submodules, what does it do poorly/not do for your needs? Thanks, Phillip Baker On Tue, Mar 31, 2009 at 7:05 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Tue, 31 Mar 2009, P Baker wrote: > >> On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> 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. > > My point was more about "you cannot just remove the subdirectory, or you > _will_ lose data". > >> >> *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. > > No. .gitmodules has the default information, and "git submodule init" > brings that into .git/config, to be overridden by the user if she so > likes. > >> >> *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. > > No. Not at all. At least in my usage, submodules are mostly optional. > IOW I have ways in my projects to cope with the absence of a checkout. > >> >> *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. > > Complexity is often a good sign of bad design. > > In this case, I want to point out that there has been a better design > already: > > http://thread.gmane.org/gmane.comp.version-control.git/114545 > > (Unfortunately, Daniel decided to post the follow-up patches in different > threads; that will make it hard for you to find them.) > > Ciao, > Dscho > > -- 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
