Am 24.03.2011 23:01, schrieb Fredrik Gustafsson: > Hi, > I'm interested in working as a student for git in the GSOC program this > year. > > I'm running a lot of web projects with heavy use of git submodules (each > project has around 40 submodules) and therefore I'm very interested in > enchant the git submodule experience. Great to hear that! > I'm asking for your oppinions and idées for my planned todolist for this > summer (if I get accepted of course). > > == Preventing false "pointers" == > It's far too easy to push a gitrepo pointing to a submodule version that > is not existing on the server. Prevent this by checking for available > submodule versions before acceptingt the push. Yes, requiring to force such a push is an issue raised quite often (I think addressing this issue would be a good starting point for people who want to get involved in enhancing the submodule experience). > == Threat every module alike == > When failing fetching a submodule, continue fetching the next one > instead of dying. There's no need to prevent fetching a submodule > beginning at 'z' just because a failing in fetching a submodule > beginning at 'a'. The submodules should not be alphabetically dependant > as they are now. I assume you are talking about the implicit fetch done by "git submodule update" here. The recursive submodule fetch that "git fetch" learned recently continues to fetch other submodules even if one or more fetches failed. But you are right that "git submodule update" should attempt to continue updating the remaining submodules too even if one of those updates failed along the way (This should be achieved with even less effort than the push issue mentioned above, so it would be an even easier starting point for people who want to get involved). > == Make submodule changes globally visible == > Give git-log submodule support. A git log of showing a new version of a > module should (if choosen by --submodules or alike) also list the > changes to that submodule since the last version of the submodule was > commited. Yeah, adding an option so the user is able to tell "git log" she wants to see all submodule commits in detail too would also be very nice (Also some other commands could profit from being able to tell them to recurse into submodules). > == Move submodules into core == > This last bit is excellent described in the link below. Assuming that you are referring to placing the repository for each populated submodule in the superproject's $GIT_DIR/modules, me thinks that that is the core part of this GSoC project. So I'd be very glad to have someone on board who wants to solve this issue. > So, what do you all think? Is it too much? Too little? Is the quests > relevant to git? I like it! I think all these issues are relevant to achieve better submodule support in git and I'm looking forward to see a student (maybe you? ;-) starting to work on this. (And, as every year, it's a good idea for a prospective student to get involved in the git community before his application is accepted ... sending some patches is a good way to do that, maybe regarding one of the first two issues raised here? ;-) -- 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