GSoC 2012 application process

GSoC 2012 application process

[Jeff King]

The Google Summer of Code 2012 application process is underway. We have
participated for the past 5 years, so I assume we want to do so again.

If you don't know what GSoC is, read this:

  https://code.google.com/soc/

I've volunteered to be the organization admin again, but I would be
happy to step aside if somebody else wants to do it. I've started things
off by posting a draft of our application and starting a wiki page for
project ideas:

  https://github.com/peff/git/wiki/SoC-2012-Application

  https://github.com/peff/git/wiki/SoC-2012-Ideas

The application is due March 9th (next Friday).

At this point, we need:

  1. Somebody to volunteer as a backup admin.

  2. Project ideas to be added to the ideas page.

  3. Volunteers to mentor students.  Our criteria for mentors in the
     past has been to accept only those who have a history of
     contributing to git. But if you have an idea for a project and
     don't feel that you would be capable of mentoring, please feel free
     to start a discussion on the list. You may interest other people
     who can volunteer to mentor for it.

  4. People to read over the application and suggest improvements. It's
     adapted from last year's application. The general meaning should be
     the same, though I did bring it up to date as well clean up a few
     awkward bits.

In the past, we've used the kernel.org wiki for developing the SoC
materials. However, it's still not editable, and I don't think we have a
plan for what the "new" git wiki will be. I've put things up on this
GitHub wiki in the meantime; they can be migrated to an official wiki if
and when that happens.

I think you'll need a GitHub login to edit the wiki pages via the web
interface. You can also clone it here:

  git://github.com/peff/git.wiki.git

and I will be happy to take patches on the list.

-Peff

[git wiki PATCH 1/3] "Improving parallelism in various commands" project

[Thomas Rast]

---
 SoC-2012-Ideas.md |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 29a374a..145b379 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -68,3 +68,34 @@ work to be done:
    and only accessed on demand.
 
 Proposed mentor: Jeff King
+
+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.
+
+Proposed by: Thomas Rast
+Possible mentor(s): Thomas Rast
-- 
1.7.9.2.467.g7fee4

[git wiki PATCH 2/3] "Designing a faster index format" project

[Thomas Rast]

---
 SoC-2012-Ideas.md |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 145b379..59d1baf 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -99,3 +99,44 @@ computers is a plus.
 
 Proposed by: Thomas Rast
 Possible mentor(s): Thomas Rast
+
+Designing a faster index format
+-------------------------------
+
+Git is pretty slow when managing huge repositories in terms of files
+in any given tree, as it needs to rewrite the index (in full) on
+pretty much every operation.  For example, even though _logically_
+`git add already_tracked_file` only changes a single blob SHA-1 in the
+index, Git will verify index correctness during loading and recompute
+the new hash during writing _over the whole index_.  It thus ends up
+spending a large amount of time simply on hashing the index.
+
+A carefully designed index format could help in several ways.  (For the
+complexity estimates below, let n be the number of index entries or
+the size of the index, which is roughly the same.)
+
+ * The work needed for something as simple as entering a new blob into
+   the index, which is possibly the most common operation in git
+   (think `git add -p` etc.) should be at most log(n).
+
+ * The work needed for a more complex operation that changes the
+   number of index entries will have to be larger unless we get into
+   database land.  However the amount of data that we SHA-1 over
+   should still be log(n).
+
+ * It may be possible to store the cache-tree data directly as part of
+   the index, always keeping it valid, and using that to validate
+   index consistency throughout.  If so, this would be a big boost to
+   other git operations that currently suffer from frequent cache-tree
+   invalidation.
+
+Note that there are other criteria than speed: the format should also
+be as easy to parse as possible, so as to simplify work for the other
+.git-reading programs (such as jgit and libgit2).  For the same
+reason, you will also have to show a significant speed boost as
+otherwise the break in compatibility is not worth the fallout.
+
+The programming work will be in C, as it replaces a core part of git.
+
+Proposed by: Thomas Rast
+Possible mentor(s): Thomas Rast
-- 
1.7.9.2.467.g7fee4

[git wiki PATCH 3/3] "Improving the `git add -p` interface" project

[Thomas Rast]

---
 SoC-2012-Ideas.md |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 59d1baf..b2cc475 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -140,3 +140,44 @@ The programming work will be in C, as it replaces a core part of git.
 
 Proposed by: Thomas Rast
 Possible mentor(s): Thomas Rast
+
+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.
+
+Proposed by: Thomas Rast
+Possible mentor(s): Thomas Rast
-- 
1.7.9.2.467.g7fee4

Re: [git wiki PATCH 2/3] "Designing a faster index format" project

[Jeff King]

On Fri, Mar 02, 2012 at 12:05:46PM +0100, Thomas Rast wrote:

> ---
>  SoC-2012-Ideas.md |   41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)

Thanks, I've applied and pushed all three (but the index one is my
favorite).

-Peff

Re: [git wiki PATCH 1/3] "Improving parallelism in various commands" project

[Nguyen Thai Ngoc Duy]

On Fri, Mar 2, 2012 at 6:05 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> + * 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.

I just had a thought this afternoon whether "git add" may benefit from
parallelism. It's most likely I/O-bound, although I think if we add a
bunch of large files, it might become CPU-bound. To generalize,
anything that calls hash_sha1_file() might benefit from parallelism.

Another candidate may be git-apply. Actually I just want to speed up
git-rebase and think git-apply may be the culprit. Or it could be
unpack-trees code..
-- 
Duy

Re: GSoC 2012 application process

[Nguyen Thai Ngoc Duy]

On Fri, Mar 2, 2012 at 4:11 PM, Jeff King <peff@peff.net> wrote:
> At this point, we need:
>
>  2. Project ideas to be added to the ideas page.

The master index to speed up pack access by avoid going through all
pack indices one by one when there are a lot of packs. If building the
master index is cheap, it could take "repack -ad"'s position in "gc
--auto" and delay repacking longer. I think this should be easy to do,
just not sure big enough for gsoc.
-- 
Duy

Re: [git wiki PATCH 1/3] "Improving parallelism in various commands" project

[James Pickens]

[Resend since the first try had HTML and the list rejected it]

On Fri, Mar 2, 2012, Thomas Rast <trast@student.ethz.ch> wrote:
+ * 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.

For those of us who must work on NFS for various reasons, it would help
tremendously to write out work tree files in parallel, during 'git clone',
'git reset --hard', and any other command that writes lots of files to the
work tree.  You can get a huge speedup (benchmarked at ~3.5x) without even
unpacking those files in parallel; unpacking them serially and writing them
to disk in parallel is sufficient.

I submitted a patch [1] ~2 years ago that added that capability.  It was
not accepted, but it did demonstrate the huge potential speedup on NFS, and
the pitfall of degrading performance on a local drive.  The patch itself is
probably not useful any more, but it includes some benchmarks, and the
discussion may be helpful.

James

[1] http://thread.gmane.org/gmane.comp.version-control.git/103489

Re: [git wiki PATCH 2/3] "Designing a faster index format" project

[Junio C Hamano]

Having harder and more ambitious ones in the mix is OK, but I suspect this
one is probably a bit too ambitious to be realistic for a student project
that lasts only 3 months.

This proposal is about a change that touches core parts of the system that
has the chance of inflicting permanent damage to end users' histories.
I'd have a hard time reviewing and convincing myself that the change is
good, if such a change were done by somebody new to the system, even if
the work were mentored very closely by one of our top 15 committers.

Re: GSoC 2012 application process

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ... a wiki page for
> project ideas:
>
>   https://github.com/peff/git/wiki/SoC-2012-Application
>   https://github.com/peff/git/wiki/SoC-2012-Ideas
>
> The application is due March 9th (next Friday).

Thanks for getting the ball rolling.

One thing unrelated to the proposal I have been wondering about was how
well our release cycles mesh with the GSoC timeline.

Comparing the GSoC timeline and the Git Calendar:

    http://www.google-melange.com/gsoc/events/google/gsoc2012
    http://tinyurl.com/gitcal

Some basics to consider:

 - Typically one cycle of our development lasts for 8 to 10 weeks, and at
   around its 5th or 6th week, the major changes for the next release are
   expected to be more or less ready.

 - As we have about 20 weeks between the beginning of post-1.7.10 cycle
   and pencils-down time for GSoC, and also people tend to slow down or
   stop late June to early July for summer holidays, I am planning to make
   these cycles last a bit longer for 10 weeks.

The way I envision the experience for this year's students would go are
like this:

 * GSoC student proposal acceptance (April 23rd)
   The students are expected to start "bonding" with the community.

   This is at the beginning of week #4 of the post-1.7.10 cycle.  Students
   have a chance to observe and learn how a change is proposed, its design
   debated and patchset polished from beginning to end, even if they wait
   before joining the mailing list until this date.

 * GSoC student first day of business (May 21st)
   The students are expected to start coding.

   This is at the beginning of week #8 of the post-1.7.10 cycle,
   1.7.11-rc0 should have been tagged several days before, and 1.7.11-rc1
   is scheduled to be tagged in a few days.  Once we hit this point, we
   usually do not queue anything large even to 'pu' until the final
   release to encourage people to concentrate on the upcoming release,
   which may be OK for the first couple of weeks for GSoC students (they
   won't have anything to show that early).

   The final batches of large changes that were previously discussed and
   polished would still be graduating to 'master', whose earlier parts of
   lifecycle the students may not have seen, but smaller and more obvious
   changes proposed after they joined the community would go their full
   lifecycle from 'pu' thru 'next' down to 'master', and the students can
   learn from these topics how the development process works.

 * Beginning of post 1.7.11 cycle (June 11th)
   The students would be working furiously for midterm.

   At this point, the students have worked for 3 weeks with their mentors.
   Good students may at least have design sketches ready to be presented
   at this point, if not a working code.

 * GSoC midterm evaluation (July 9th)

   This is at the beginning of week #5 of the post-1.7.11 cycle.  The
   student's changes should at be ready for 'pu' by this time, or there is
   no chance of them being in the upcoming release.

   The students would have had 7 weeks to work up to this point, and they
   have 4 more weeks to polish their work to 'next' and to 'master' until
   1.7.12-rc1, and another 2 weeks to further fix late bugs in 'master'.

 * GSoC pencils down (Aug 20th)

   This is at the end of week #10 of the post-1.7.11 cycle, and 1.7.12
   should be already out the day before.


Our release cycle was never scheduled around GSoC timeline for the past
GSoC students, so I do not know what effect, if any, our pre-release
freeze period had on our past students' work (I would appreciate hearing
from past student about their experiences).

In any case, it seems that they coincide fairly well for this year's
students.

By the way, I also considered splitting the 20-week period into two and a
half cycles, coinciding -rc1 of the third cycle after the upcoming 1.7.10
release and GSoC pencils down date. It would make the student success
criteria "Is it in 'master'?" instead of "Is it in a release?", but the
overall schedule did not work as well as the above.

Re: GSoC 2012 application process

[Jeff King]

On Fri, Mar 02, 2012 at 01:48:31PM -0800, Junio C Hamano wrote:

> One thing unrelated to the proposal I have been wondering about was how
> well our release cycles mesh with the GSoC timeline.
> [...]
> In any case, it seems that they coincide fairly well for this year's
> students.

Thanks for a thorough analysis. This isn't something we really thought
too much about in years past (and it seems like you have been paying
more attention to the scheduling in general this past year, or at least
communicating more openly about). So given that the schedule coincides
reasonably well, I think it make sense to consider this a "pilot" year,
and to make a mental note to talk post-GSoC about how the schedule
worked (or didn't work).

Part of me thinks that no matter how much schedule planning we do,
students will always go their own and deliver work in fits and starts.
It's their nature (and I say that as somebody who managed to be a
student for 24 consecutive years :) ).

> By the way, I also considered splitting the 20-week period into two and a
> half cycles, coinciding -rc1 of the third cycle after the upcoming 1.7.10
> release and GSoC pencils down date. It would make the student success
> criteria "Is it in 'master'?" instead of "Is it in a release?", but the
> overall schedule did not work as well as the above.

Actually, we have been pretty lenient with student success in the past.
Many projects have been marked successful even if their code as not yet
in master, and in many cases never made it.

I think part of that is because we are often over-ambitious with our
projects, and the mentors and students realize near the end that the
project is much large or more difficult than originally realized. To
some degree that is a good thing, as it means students are working on
cool, interesting things that haven't been done before. But it may also
be worth making an effort to split ambitious projects into bite-sized
chunks. Even if step 3 doesn't make it in, steps 1 and 2 might end up as
a good project in themselves, and that is much better than the student
contributing nothing.

In some cases, too, the student pushes forward thinking on a subject
among the project members. The rev-cache code did not end up getting
merged. But I'm not sure I would consider it a failure. It was an
interesting experiment, and I think ultimately the complexity tradeoff
was a bit distasteful. However, the negative result and the experience
gained by the community were still worthwhile.

-Peff

Re: [git wiki PATCH 2/3] "Designing a faster index format" project

[Nguyen Thai Ngoc Duy]

On Sat, Mar 3, 2012 at 1:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Having harder and more ambitious ones in the mix is OK, but I suspect this
> one is probably a bit too ambitious to be realistic for a student project
> that lasts only 3 months.
>
> This proposal is about a change that touches core parts of the system that
> has the chance of inflicting permanent damage to end users' histories.
> I'd have a hard time reviewing and convincing myself that the change is
> good, if such a change were done by somebody new to the system, even if
> the work were mentored very closely by one of our top 15 committers.

I was comparing the excitement of seeing this implemented vs packv4,
then realised the complexity of work may be more or less the same.
But, if the new format is not mmap'd for direct access, we can
reconstruct "struct cache_entry*" exactly as it is now from new
format. That makes it less sensitive to the core parts and we still
hopefully benefit from new format (mostly I/O I guess). Phase 2 could
come later to make core parts aware of new format.
-- 
Duy

[git wiki PATCH] "Modernizing and expanding Git.pm" project

[Jakub Narebski]

---
I'm not sure if my Markdown is entirely correct.

 SoC-2012-Ideas.md |   41 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 02a8fc7..f56b601 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -181,3 +181,44 @@ this project.
 
 Proposed by: Thomas Rast  
 Possible mentor(s): Thomas Rast
+
+Modernizing and expanding Git.pm
+--------------------------------
+
+Git.pm was created in 2006 to make it easy to call git commands from
+Perl scripts safely, in a portable way (including workarounds required
+for ActiveState Perl on MS Windows).  Its error handling via exceptions
+also comes from that year.
+
+Git.pm module uses Error (and Error::Simple) for its exception handling.
+Unfortunately, while it might looked like a good choice in 2006, Error
+module is deprecated:
+
+> WARNING
+> -------
+>
+> Using the "Error" module is **no longer recommended** due to the
+> black-magical nature of its syntactic sugar, which often tends to
+> break. Its maintainers have stopped actively writing code that uses
+> it, and discourage people from doing so. See the "SEE ALSO" section
+> below for better recommendations.
+
+Nowadays the recommended solution to exception handling in Perl are
+Try::Tiny (or TryCatch, but I don't think Git.pm would need this more
+heavyweight module) for capturing and handling exceptions, and
+Exception::Class (or Throwable, but that requires heavyweight Moose
+object system) for throwing OO exceptions.
+
+The major goal would be to update Git.pm to modern Perl conventions,
+amon others moving from Error / Error::Simple to Try::Tiny and
+Exception::Class, preserving backwards compatibility, but perhaps also
+adding a better interface and using it in git commands implemented in
+Perl.
+
+Other optional goals would be to extend Git.pm, for example adding
+Git::Config module which would read git configuration once like gitweb
+does, or Git::Commit module for parsing commit objects, etc.
+
+Programming language: Perl  
+Proposed by: Jakub Narębski  
+Possible mentor(s): Jakub Narębski (?)
-- 
1.7.9

Re: [git wiki PATCH] "Modernizing and expanding Git.pm" project

[Jeff King]

On Sat, Mar 03, 2012 at 10:14:41PM +0100, Jakub Narebski wrote:

> ---
> I'm not sure if my Markdown is entirely correct.
> 
>  SoC-2012-Ideas.md |   41 +++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 41 insertions(+), 0 deletions(-)

Thanks, applied. Your markdown looks fine, though I dropped the quoted
heading line here:

> +> WARNING
> +> -------

As it was difficult to tell that that large text was part of a quoted
bit (probably there is some quoting mode that does not expand such
things, but I didn't think it was worth fiddling with too much).

-Peff

[git wiki PATCH] Teaching "--3way" to "git apply"

[Junio C Hamano]

I am a bit reluctant to be the one who suggests this, as I do not want to
be in the mentoring business, given that as the maintainer, I am by
definition a large part of the process to grade the success of student
projects.

But I think I should mention this, as it is a reasonable bite-size task
for a student project that is to be completed inside one release cycle.

---
 SoC-2012-Ideas.md |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 17e07e0..aeaacb1 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -263,3 +263,16 @@ This is not as terribly complicated as it looks, because the existing networking
 
 Programming language: C89
 Possible mentor(s): Vicent Marti, Russell Belfer
+
+Teaching "--3way" to "git apply"
+--------------------------------
+
+The "-3" option "git am" understands is useful only when you are
+applying a full format-patch submission. Teaching the three-way
+fallback to underlying "git apply" would make the feature avialable in
+more use cases, and later can help making the implementation of "git
+am -3" simpler.
+
+Programming language: C89
+Suggested by: Junio C Hamano
+Possible mentors: ???

Re: [git wiki PATCH] Teaching "--3way" to "git apply"

[Jeff King]

On Sun, Mar 04, 2012 at 03:35:57PM -0800, Junio C Hamano wrote:

> I am a bit reluctant to be the one who suggests this, as I do not want to
> be in the mentoring business, given that as the maintainer, I am by
> definition a large part of the process to grade the success of student
> projects.

I don't think there is any commitment to mentor, or for us to even do a
project that is on the list. The intent of the idea list is to get
students thinking about their proposals, and hopefully discussing and
exploring the ideas with us on the list. It is only when it comes time
to read and rank student proposals that we make a commitment to an idea.

> But I think I should mention this, as it is a reasonable bite-size task
> for a student project that is to be completed inside one release cycle.

I actually think it may be a little bit too small for a whole summer
project. But I pushed it to the wiki for the reasons above; this is just
an ideas page, not a solid list of proposals.

-Peff

Re: [git wiki PATCH] Teaching "--3way" to "git apply"

[Thomas Rast]

Jeff King <peff@peff.net> writes:

> I don't think there is any commitment to mentor, or for us to even do a
> project that is on the list. The intent of the idea list is to get
> students thinking about their proposals, and hopefully discussing and
> exploring the ideas with us on the list. It is only when it comes time
> to read and rank student proposals that we make a commitment to an idea.
>
>> But I think I should mention this, as it is a reasonable bite-size task
>> for a student project that is to be completed inside one release cycle.
>
> I actually think it may be a little bit too small for a whole summer
> project. But I pushed it to the wiki for the reasons above; this is just
> an ideas page, not a solid list of proposals.

Perhaps we should spell this out in the leading text?  I was going to
send a patch, but got stuck rewording at

  Note that these are ideas, not project proposals.  As stated, they may
  not be of the right difficulty or size to be solved within one Summer
  of Code.

Maybe you can find a nicer way to write the "as stated" (I want it to
say "in the form they currently have") and put that before the first
title.

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

Re: [git wiki PATCH] Teaching "--3way" to "git apply"

[Jeff King]

On Mon, Mar 05, 2012 at 09:05:54AM +0100, Thomas Rast wrote:

> > I actually think it may be a little bit too small for a whole summer
> > project. But I pushed it to the wiki for the reasons above; this is just
> > an ideas page, not a solid list of proposals.
> 
> Perhaps we should spell this out in the leading text?  I was going to
> send a patch, but got stuck rewording at
> 
>   Note that these are ideas, not project proposals.  As stated, they may
>   not be of the right difficulty or size to be solved within one Summer
>   of Code.
> 
> Maybe you can find a nicer way to write the "as stated" (I want it to
> say "in the form they currently have") and put that before the first
> title.

I think the whole intro text is pretty bad. I just pushed the patch
below, but I'm open to suggestions.

-- >8 --
ideas: give a better introduction

The original text was just pulled from the ideas page of
previous years. Let's rework it to address our two audiences
(people adding ideas, and students reading the page)
directly. And especially let's encourage students to realize
that these ideas are just starting points, and try to get
them to engage the community before writing a proposal (or
worse, just submitting a proposal that is simply a
cut-and-paste of one of the ideas).

Signed-off-by: Jeff King <peff@peff.net>
---
 SoC-2012-Ideas.md |   25 ++++++++++++++++++++-----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index aeaacb1..0bd938a 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -1,9 +1,24 @@
 This page contains project ideas for Google Summer of Code 2012 from the
-Git user and development community. You can get started by reading some
-project descriptions, and the mailing list thread(s) that spawned them.
-If you have another idea, add it to this page and start a discussion on
-the [[git mailing
-list|https://git.wiki.kernel.org/articles/g/i/t/GitCommunity_c4e3.html#Mailing_List]].
+Git user and development community.
+
+If you're active in the git community and have an idea that you would
+feel comfortable mentoring, feel free to add it. If you have an idea but
+need to find a suitable mentor, please bring it up on the [git mailing
+list]; others can help you develop the idea and may volunteer to mentor.
+
+If you're a prospective GSoC student, read through the ideas and see if
+any interest you. But note that these are ideas, not project proposals;
+they may need details filled in or expanded to make a good project.
+Find an area that interests you and start a discussion on the [git
+mailing list], even if it's just by asking more about the topic. A good
+proposal will be clear about the problem to be solved, the history of
+work in that area, and the specifics of the approach that the GSoC
+project will take. You can find some of those answers by reading the
+code and searching the list archives, but discussing the idea with
+interested developers is a great way for both the student and mentor to
+reach an understanding of exactly what is to be accomplished.
+
+[git mailing list]: https://git.wiki.kernel.org/articles/g/i/t/GitCommunity_c4e3.html#Mailing_List
 
 Better git log --follow support
 -------------------------------
-- 
1.7.9.1.11.g9d81f

Re: GSoC 2012 application process

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

>   https://github.com/peff/git/wiki/SoC-2012-Ideas
[...]
>   2. Project ideas to be added to the ideas page.

They're not really SoC project ideas, but if you're interested in
smaller project ideas, I had gathered some last year on Git's wiki
(originally as suggestion to students as a school project):

  https://git.wiki.kernel.org/articles/s/m/a/SmallProjectsIdeas_00e5.html

I can either add a link to this page on the ideas list, or convert this
page to markdown syntax to add it to the wiki.

I'll have to revive this list anyway since I'll offer the same school
project this year in May-June.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2012 application process

[Jeff King]

On Mon, Mar 05, 2012 at 02:38:14PM +0100, Matthieu Moy wrote:

> They're not really SoC project ideas, but if you're interested in
> smaller project ideas, I had gathered some last year on Git's wiki
> (originally as suggestion to students as a school project):
> 
>   https://git.wiki.kernel.org/articles/s/m/a/SmallProjectsIdeas_00e5.html

I do think they're interesting, though probably not a good fit for the
SoC ideas page because of their size.

> I can either add a link to this page on the ideas list, or convert this
> page to markdown syntax to add it to the wiki.

I'd rather have them on a separate page. Which brings up the question of
whether they should be moved at all. I had never intended for this wiki
to be the official git wiki. I just wanted a convenient place to stick
GSoC stuff, and I didn't want to deal with the official wiki question.

So where do people want the wiki? It would be easy to host it somewhere
more official looking, like https://github.com/git/git/wiki. David
mentioned that Google Code has wikis which are backed by git now. I have
no idea if kernel.org is ever planning on bringing back an editable
wiki.

Wherever the actual hosting occurs, we could also probably get a nicer
name like wiki.git-scm.com.

-Peff

Re: GSoC 2012 application process

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

>>   https://git.wiki.kernel.org/articles/s/m/a/SmallProjectsIdeas_00e5.html
[...]
>> I can either add a link to this page on the ideas list, or convert this
>> page to markdown syntax to add it to the wiki.
>
> I'd rather have them on a separate page. Which brings up the question of
> whether they should be moved at all.

Right now, they don't need to, but having them as static pages with
strange name (I had to guess the 00e5 part of the URL to find the
page ...) is not optimal when it comes to editing ;-). Nothing urgent
though. Scott said he had plans to host a wiki on git-scm.com, it can
probably wait until that.

I think it makes sense to add a link, so that more generally than the
SoC context, pages containing ideas link to each other. How about this:

>From c7ab11696f777e70e6bc254424f54bc884e52758 Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Mon, 5 Mar 2012 15:37:06 +0100
Subject: [PATCH] Add links to other sources of inspiration

---
 SoC-2012-Ideas.md |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 0bd938a..6f543f6 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -291,3 +291,13 @@ am -3" simpler.
 Programming language: C89
 Suggested by: Junio C Hamano
 Possible mentors: ???
+
+Other sources of inspiration
+----------------------------
+
+* Previous year's SoC ideas:
+[SoC2011Ideas](https://git.wiki.kernel.org/articles/s/o/c/SoC2011Ideas_49fd.html),
+[SoC2010Ideas](https://git.wiki.kernel.org/articles/s/o/c/SoC2010Ideas_ccd4.html)
+* [Git users survey](http://permalink.gmane.org/gmane.comp.version-control.git/183242)
+* [Small project ideas](https://git.wiki.kernel.org/articles/s/m/a/SmallProjectsIdeas_00e5.html)
+(probably too small for a SoC)
-- 
1.7.9.111.gf3fb0.dirty



-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2012 application process

[Jeff King]

On Mon, Mar 05, 2012 at 03:42:23PM +0100, Matthieu Moy wrote:

> I think it makes sense to add a link, so that more generally than the
> SoC context, pages containing ideas link to each other. How about this:

Makes sense to me. Applied and pushed.

-Peff

GSoC backup admin

[Jeff King]

On Fri, Mar 02, 2012 at 04:11:14AM -0500, Jeff King wrote:

> The Google Summer of Code 2012 application process is underway. We have
> participated for the past 5 years, so I assume we want to do so again.
> [...]
> At this point, we need:

People have been very good about contributing to the ideas page, and I
think we have a number of possible mentors (though more ideas and more
mentor volunteers are always good). However, we still need somebody to
volunteer as backup admin. If I don't hear from somebody, I will just
put down Shawn's name, whether he accepts it or not. :)

-Peff

Re: GSoC backup admin

[Shawn Pearce]

On Wed, Mar 7, 2012 at 06:36, Jeff King <peff@peff.net> wrote:
> On Fri, Mar 02, 2012 at 04:11:14AM -0500, Jeff King wrote:
>
>> The Google Summer of Code 2012 application process is underway. We have
>> participated for the past 5 years, so I assume we want to do so again.
>> [...]
>> At this point, we need:
>
> People have been very good about contributing to the ideas page, and I
> think we have a number of possible mentors (though more ideas and more
> mentor volunteers are always good). However, we still need somebody to
> volunteer as backup admin. If I don't hear from somebody, I will just
> put down Shawn's name, whether he accepts it or not. :)

I'm game with being backup admin again this year.

[gsoc2012 wiki PATCH] "Use JavaScript library / framework in gitweb" project

[Jakub Narebski]

---
Inspied by problems with timezone changing JavaScript that Ramsay
Jones had.

 SoC-2012-Ideas.md |   54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 6f543f6..8c3b266 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -264,6 +264,60 @@ Programming language: Perl
 Proposed by: Jakub Narębski  
 Possible mentor(s): Jakub Narębski (?)
 
+Use JavaScript library / framework in gitweb
+--------------------------------------------
+
+Gitweb (git web interface) includes some *optional* client-side
+scripting using JavaScript.  This includes checking if JavaScript is
+available and remembering this information so gitweb can choose
+JavaScript-only version of a view (javascript-detection), selecting
+common timezone to use when showing dates (adjust-timezone), and
+AJAX-y incremental blame view (blame_incremental).
+
+Currently all this is done using hand-written JavaScript.  This means
+that gitweb scripting includes handling cookies, formatting output,
+processing dates, and smoothing out incompatibilities between browsers
+(like e.g. XmlHttpRequest creation).
+
+This is redoing work which JavaScript libraries, such as jQuery,
+MooTools or YUI already did.  Moreover, if we want to add new features
+(e.g. table sorted using JavaScript), or improve existing ones, we
+would have to re-implement existing JavaScript code.  Also our
+hand-crafted code is not as well tested as widely used JavaScript
+libraries.
+
+The goal of this project is to move gitweb client side scripting to
+use some JavaScript library / JavaScript framework.
+
+The project would consist of the following steps:
+
+ * Add support for configuring and loading external JavaScript library
+   to `gitweb/gitweb.perl` and `gitweb/Makefile`.  It would be nice
+   (though not necessary) to be able to use local version of library,
+   and have such feature well documented.
+
+ * Remove gitweb's JavaScript mini-library in `gitweb/static/js/lib`
+   and replace it part by part by appropriate JavaScript library
+   functions (methods).
+
+ * Replace DOM selectors by library version, if applicable.
+
+ * Optional: emulate 'onprogress' in XmlHttpRequest using native
+   JavaScript library mechanism (creating a class, or whatever).
+
+ * Optional: better deferring of repainting in incremental blame.
+
+Note that we require that client-side scripting in gitweb follow
+[progressive enhancement] strategy; gitweb should work correctly,
+perhaps with reduced functionality, even if JavaScript is turned off,
+or external JavaScript library cannot be loaded.
+
+[progressive enhancement]: http://en.wikipedia.org/wiki/Progressive_enhancement
+
+Programming language: JavaScript  
+Proposed by: Jakub Narębski  
+Possible mentor(s): Jakub Narębski
+
 Finishing network support for libgit2
 -------------------------------------
 
-- 
1.7.9

Re: [gsoc2012 wiki PATCH] "Use JavaScript library / framework in gitweb" project

[Jeff King]

On Thu, Mar 08, 2012 at 10:18:13PM +0100, Jakub Narebski wrote:

> Inspied by problems with timezone changing JavaScript that Ramsay
> Jones had.
> 
>  SoC-2012-Ideas.md |   54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 54 insertions(+), 0 deletions(-)

Thanks, applied.

-Peff

[gsoc2012 wiki PATCH] "`git instaweb --serve`" project

[Jakub Narebski]

---
I don't know if "git-serve" is something that would be realy useful,
or just checkmark in the comparison of Git and Mercurial.

 SoC-2012-Ideas.md |   54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 95411ec..884237e 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -318,6 +318,60 @@ Programming language: JavaScript
 Proposed by: Jakub Narębski  
 Possible mentor(s): Jakub Narębski
 
+`git instaweb --serve`
+----------------------
+
+[git-instaweb] is a tool for browsing a repository (in gitweb) with
+a web browser.  To use it, simply run `git instaweb` inside
+repository.  It would set up gitweb and a web server, and by default
+also run a web browser.  Web interface would be available at
+`http://localhost:1234`.
+
+For informal, ad-hoc sharing it would be nice if there was an option
+to `git instaweb` that would make it also allow remote machines
+to **pull** from you (via HTTP), similar to [hg serve] command in
+Mercurial version control system.
+
+git-instaweb supports many web servers.  Currently apache2, lighttpd,
+mongoose, plackup and webrick are supported.  It is not necessary to
+implement support for `--serve` in all of them.
+
+The project would consist of the following steps:
+
+ * Configure web server to run `git-http-backend` CGI program to serve
+   git repositories over HTTP.  It should probably allow by default
+   only read-only use.
+
+ * Configure gitweb to show fetch URL in 'summary' page.
+
+ * If possible for given web server (and with available modules),
+   configure it so that "smart" HTTP server and gitweb share common
+   URL (are available under the same URL).
+
+ * If possible use mechanism native for a web server used, for example 
+   [Plack::App::GitSmartHttp] for 'plackup' web server, or [grack]
+   with WEBrick.
+
+ * Optionally: add support for pushing (disabled by default).
+
+ * Optionally: add documentation about using `git instaweb` to
+   "[Git User's Manual]" (or one of tutorials), similar to appropriate
+   chapter in [hgbook] ("Mercurial: The Definitive Guide").
+
+The minimum would be to implement pull support under different URL
+than web interface, and only for one web server.
+
+Programming language: shell script  
+Proposed by: Jakub Narębski  
+Possible mentor(s): Jakub Narębski, Eric Wong, ...
+
+[git-instaweb]: http://schacon.github.com/git/git-instaweb.html
+[hg serve]: http://mercurial.selenic.com/wiki/hgserve
+[Plack::App::GitSmartHttp]: http://search.cpan.org/perldoc?Plack::App::GitSmartHttp
+[grack]: https://github.com/schacon/grack
+[Git User's Manual]: http://schacon.github.com/git/user-manual.html
+[hgbook]: http://hgbook.red-bean.com/read/collaborating-with-other-people.html#sec:collab:serve
+
 Finishing network support for libgit2
 -------------------------------------
 
-- 
1.7.9

[gsoc2012 wiki PATCH] "Graphical diff in git-gui" project

[Jakub Narebski]

---
I don't have much hope that we can find a student that would be
interested in this feature and knows Tcl/Tk enough so that hs or she
can atually implement it...

But I can hope.

 SoC-2012-Ideas.md |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/SoC-2012-Ideas.md b/SoC-2012-Ideas.md
index 9ad449f..bea2c09 100644
--- a/SoC-2012-Ideas.md
+++ b/SoC-2012-Ideas.md
@@ -421,6 +421,68 @@ Write a tool that can be used for the task, and optionally wrap an interactive U
 Programming language: Any  
 Possible mentors: ???  
 
+Graphical diff in git-gui
+-------------------------
+
+[git-gui] is a portable Tcl/Tk based graphical interface to Git,
+focused on commit generation and single file annotation.  It is part
+of Git, even though it is developed in a [separate repository].
+
+git-gui can show differences as syntax-highlighted unified diff.  The
+goal of this project would be to add graphical side-by-side diff.
+One possibility is to make use of [TkDiff] code (a graphical diff and
+merge tool), which is also GPL licensed.
+
+The project would consist of the following steps (not all must be
+implemented during Google Summer of Code):
+
+ * Add "git gui diff" subcommand, which would show single file
+   side-by-side graphical compare or/and graphical diff.
+
+   Graphical part and code for side-by-side compare (showing full
+   contents of both files) can be taken from TkDiff, while graphical
+   side-by-side diff (showing changes plus context) can be translated
+   from gitweb's side-by-side diff code.
+
+ * Integrate graphical diff with main git-gui application (including
+   switching between side-by-side and unified diff).
+
+ * Add highlighting of changes in diff both to side-by-side
+   (new code), and to unified diff (current code).
+
+   It can be done using code for TkDiff (perhaps with Git performing
+   word diff instead of doing it in Tcl), or/and using algorithm from
+   gitweb and diff-highlight in contrib.  The difference is that one
+   uses word diff or character diff to highlight changes, the other
+   just skips common prefix and suffix.
+
+ * Add graphical merge / graphical 3-way diff support.  Both are to be
+   used in case a file has textual conflicts; graphical merge also
+   includes resolving a merge by taking 'our' side, 'their' side (or
+   optionally also 'ancestor' side), or by editing merge result.
+
+ * Graphical side-by-side tree level diff, or side-by-side directory
+   listing with differences highlighted.
+
+   UI can be taken from two-panel filemanagers (like MC, or Total
+   Commander), or from synchronization tools (like e.g. Unison).
+
+   The difficulty can be in showing rename and copy detection results,
+   and in showing type (filemode) changes.
+
+The minimum would be to implement side-by-side diff or side-by-side
+compare of two files, without highlighting changes (diff refinement
+highlighting) in the form of separate "`git gui diff <file>`"
+command.
+
+[git-gui]: http://schacon.github.com/git/git-gui.html
+[separate repository]: http://repo.or.cz/w/git-gui.git
+[TkDiff]: http://freecode.com/projects/tkdiff
+
+Programming language: Tcl/Tk  
+Proposed by: Jakub Narębski  
+Possible mentor(s): Pat Thoyts, Paul Mackerras (?)
+
 Other sources of inspiration
 ----------------------------
 
-- 
1.7.9