Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra <artagnon@gmail.com>]

Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>
>> I will do it again, if people feel strongly about Git being a part of
>> it. However, I have gotten a little soured on the GSoC experience. Not
>> because of anything Google has done; it's a good idea, and I think they
>> do a fine of administering the program. But I have noticed that the work
>> that comes out of GSoC the last few years has quite often not been
>> merged, or not made a big impact in the codebase, and nor have the
>> participants necessarily stuck around.
>
> I think that if we can commit enough time to mentor well it's
> worthwhile.  Even such a negative result is useful, since it can teach
> us how good or poor we are at bringing new contributors in and what
> parts of that process need more work.

The point is that we must be willing to spend time learning what went
wrong the previous summer, and how to improve upon it.  There's no
point in doing a lather-rinse-repeat after many consecutive failures.

> Some potential projects (unfiltered --- please take them with a grain
> of salt):
>
>  - cross-compilable git

Why, exactly?  Git for embedded devices?

>  - incorporation of the cgit web interface, or formalizing a subset of
>    libgit.a to export as a stable library to it

I didn't understand this: you want cgit in-tree?

>  - moving forward on a project that was the subject of a previous
>    gsoc project: line-level logging, "rebase --interactive" on top of
>    sequencer, usable svn remote helper

I can't see a roadmap for gradually phasing out `rebase -i` as more
and more of its functionality is built into the sequencer.  Would you
start by using `cherry-pick --continue` in the special case of
consecutive `pick` or `revert` operations (yuck)?  The sequencer
currently has a continuation logic that we can leverage, but how will
it call out to shell functions to do specific tasks (like `fixup`,
which is not yet implemented)?  Really, the only way I see is to
duplicate the functionality of `rebase -i` in C, and throw away the
shell script when we're sure we're done.

For usable svn remote helper, the major TODO is a git -> svn bridge.
My previous effort (which was a long time) was stalled because we
needed a way to persist blobs of text referenced by marks, and
retrieve them on demand.  Building this bridge is hard enough already,
and I think we should just focus on an independent git -> svn bridge
to put into contrib/svn-fi as a deliverable.  It doesn't have to have
anything to do with remote helpers at all.

>  - drag-and-drop cherry-pick in gitk

You expect someone to write Tcl/Tk today?  Do a `git log gitk-git/`
and tell me how many people are writing it.

>  - a sub-library of code shared with libgit2 (might be hard because
>    our notions of strings are different :().
>
>  - assimilating the distro builds: "make deb-pkg", "make rpm-pkg",
>    etc along the same lines as the linux kernel's script/package/,
>    to help people get recent git installed when they want it

Overkill.  I just symlink to bin-wrapper/git from a place high up in
my $PATH.  If anything, we should be making it easier for ourselves to
run different versions of git right from $HOME, much like rbenv.
System-wide installs are taken care of by the distribution package
managers, and I doubt they need any help from us.

>  - collaborative notes editing: fix the default notes refspec,
>    make sure the "notes pull" workflow works well and is documented
>    well, offer an easy way to hide private notes after the fact
>    without disrupting public history

I personally don't care for notes much, because I can't see practical
usecases.  I'd much rather fix something that's much more widely used
and broken: submodules.