Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 18, 2013, 21:11 UTC
Message-ID: <20130218211101.GA4022@elie.Belkin>
In-Reply-To: <CALkWK0mKZLotuu7pEM_3Of3i6JzU12QV_pHxOZTUr22TOq3PeQ@mail.gmail.com>

Ramkumar Ramachandra wrote:

> Jonathan Nieder wrote:

>>  - cross-compilable git
>
> Why, exactly?  Git for embedded devices?

My personal motivation would be building Git for Windows while spending as little time on Windows as possible. People deploying git to 32-bit x86, 64-bit x86, and ARM (think "ARM laptops") might also find it handy.

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

Yes, or a stable API that cgit out-of-tree can use.

Show 6 quoted lines

>>  - 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.

It's a break-the-world thing.  "rebase -i --experimental".

[...]

> For usable svn remote helper, the major TODO is a git -> svn bridge.

There are other major TODOs, too.

[...]

>>  - drag-and-drop cherry-pick in gitk
>
> You expect someone to write Tcl/Tk today?

Sure, why not?  Tcl is not actually too unpleasant of a language.

Maybe it has a prerequisite, though:

 - "modular gitk" (splitting gitk into digestible pieces)

[...]

>>  - assimilating the distro builds:

[...]

> Overkill.

My itch is that it would let me send packaging patches to the list and get the usual high-quality feedback. Oh well. ;-)

[...]

Show 7 quoted lines

>>  - 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.

Are you sure that's not because of the poor current state of collaborative notes editing?

Some example use cases:

 - marking regressions discovered later, to warn people bisecting or
   cherry-picking

 - matching up to corresponding commits in another repository

 - link to corresponding mailing list discussion, blog post, or
   related patches

 - a wiki-like document storing review comments

 - marking which CVE this fixes, once the CVE number has been
   allocated

 - "a tour of the project" for new contributors, using explanatory
   notes that end with a mention the next commit to look at

I'm not married to the current implementation, but I think the basic idea of "git notes" is a promising feature that could use some polish.

Jonathan