Re: GSOC proposal

[Jens Lehmann <Jens.Lehmann@web.de>]

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? ;-)