On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > OK, enough, onto the project list! > > http://git.or.cz/gitwiki/SoC2008Ideas 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". .... -- 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
