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
