Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast <trast@student.ethz.ch>]

Thomas Rast <trast@inf.ethz.ch> writes:

> * We should prepare an "ideas page"[...]
>     https://github.com/trast/git/wiki/SoC-2013-Ideas

>From where I'm currently sitting, I won't have the time to mentor this
year.  So my two earlier proposals are essentially up for grabs:

1. Improving parallelism in various commands
   -----------------------------------------
 
   Git is mostly written single-threaded, with a few commands having
   bolted-on extensions to support parallel operation (notably git-grep,
   git-pack-objects and the core.preloadIndex feature).
 
   We have recently looked into some of these areas and made a few
   optimizations, but a big roadblock is that pack access is entirely
   single-threaded.  The project would consist of the following steps:
 
    * In preparation (the half-step): identify commands that could
      benefit from parallelism.  `git grep --cached` and `git grep
      COMMIT` come to mind, but most likely also `git diff` and `git log
      -p`.  You can probably find more.
 
    * Rework the pack access mechanisms to allow the maximum possible
      parallel access.
 
    * Rework the commands found in the first step to use parallel pack
      access if possible.  Along the way, document the improvements with
      performance tests.
 
   The actual programming must be done in C using pthreads for obvious
   reasons.  At the very least you should not be scared of low-level
   programming.  Prior experience and access to one or more multi-core
   computers is a plus.

This one is probably still a contender.  However, it might be worth
first looking into whether using libgit2 for pack reading would be
easier and faster, since it is written to be reentrant from the ground
up.


2. Improving the `git add -p` interface
   ------------------------------------

   The interface behind `git {add|commit|stash|reset} {-p|-i}` is shared
   and called `git-add--interactive.perl`.    This project would mostly
   focus on the `--patch` side, as that seems to be much more widely
   used; however, improvements to `--interactive` would probably also be
   welcome.

   The `--patch` interface suffers from some design flaws caused largely
   by how the script grew:

    * Application is not atomic: hitting Ctrl-C midway through patching
      may still touch files.

    * The terminal/line-based interface becomes a problem if diff hunks
      are too long to fit in your terminal.

    * Cannot go back and forth between files.

    * Cannot reverse the direction of the patch.

    * Cannot look at the diff in word-diff mode (and apply it normally).

   Due to the current design it is also pretty hard to add these features
   without adding to the mess.  Thus the project consists of:

    * Come up with more ideas for features/improvements and discuss them
      with users.

    * Cleanly redesigning the main interface loop to allow for the above
      features.

    * Implement the new features.

   As the existing code is written in Perl, that is what you will use for
   this project.

This has already featured twice, and resulted in proposals that were
insufficiently advanced and too little work for a GSoC.  If nobody feels
like extending it to a bigger project, I'll just scrap it.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch