Re: GSoC 2008 - Mentors Wanted!

On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:

Gitster talked today about libification as a project for the GSoC (I mangled some comments, I accept complaints):

gitster> For the record, i've never said I am not interested in libification.

gitster> However.

gitster> (1) I know of many places whose design is based on run-once-and-exit, and that was done for very good reasons (simpler clean-up, no risk of reusing stale data, simpler codepath in general), and

cehteh> gitster: yes anyone is interested .. i rather meant it would be nice if you and others make it primary concern for accepting patches/future development imo .. but well yes still your decision, just a mild critic

* cehteh currently uses libgit and doesnt really feel comfortable with it

gitster> (2) cleaning up to make functions re-entrant can happen incrementally, but should not have horrible performance issues for run-once-and-exit users --- see what we did to libify merge_base(), for example, as that one is done the right way;

cehteh> yes

cehteh> we could even #ifdef LIBGIT or such for cleanup/reentrancy stuff .. but someone has to lead supervise that, and others shouldent throw bricks in the way which still sometimes happens

gitster> (3) and I know it would be a very large effort to do it all, so a project that can be described with an umbrella "libification" name would exceed GSoC size.

gitster> (4) and "should not" list in (2) includes maintainability. Mindless #ifdefs are out.

gitster> So, I would not oppose it, but I just warn anybody that this is a long term subproject. I won't have time to commit myself on it, unless everybody will be happy not to see any new developments merged outside libification, that is.

gitster> So "libify merge-base" would have been a focused and well defined subproject of GSoC size. "libification" is not.

cehteh> ack

gitster> So was "libify the active_cache[] access".

gitster> "rewrite git-submodule, put the repository for submodules in the superproject $GIT_DIR/modules, and use .git-file (currently in 'pu') to point at it", would be a good sized one.

gitster> "refine diffcore-rename to add a postprocessing phase so that if we find rename from i386/foo.c to x86/foo.c but i386/bar.c was rewritten too much and did not match new x86/bar.c make them match" would be a good one as well. Throw in "refine diffcore-rename further so that it can tell a whole directory movement by summarizing the constituent files' movement" and you will get a gold star ;-)

gitster> "teach 3-way fallback logic git-am has to git-apply".

....