Re: GSoC 2008 - Mentors Wanted!

["Carlos Rica" <jasampler@gmail.com>]

On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> 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".

....