Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 8 July 2008, Jakub Narebski wrote:

> I'd very much like to have (or perhaps to wrote) some sort of interim 
> progress report for Google Summer of Code 2008 projects on 
> http://git.or.cz/gitwiki/SoC2008Projects.  Therefore I'd like you to 
> expand and/or correct those mini-summaries below.

Here is a bit late summary of this thread (and of information gathered
elsewhere).  I'll try to add this information to wiki page in approx
two days from now... of course unless project student or mentor wouldn't
do it first.
 

1. GitTorrent
 
Student: Joshua Roys
Mentor: Sam Vilain

I never got more response than "it is going slower than I would like, 
[...] Other than that, it's going well, I think." from Joshua Roys.

Mailing list archives for gittorrent mailing list doesn't show anything 
interesting, either (last post is from 2007).
  http://lists.utsl.gen.nz/pipermail/gittorrent/

Besides canonical repository gitweb
  http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
there is also mirror at
  http://repo.or.cz/w/VCS-Git-Torrent.git

There is some activity there... but no summary of it anywhere I could 
find. (I wonder if this was the project Johannes and Shawn were talking 
about of "going dark" in GSoC 2008 podcast 018...)


2. git-statistics
 
Student: Sverre Rabbelier
Mentor: David Symonds
 
There were some posts about how git-statistics can be used:
  http://thread.gmane.org/gmane.comp.version-control.git/81534
  http://thread.gmane.org/gmane.comp.version-control.git/82027
There is post with link to different git.git statictics:
  "[GitStats] Bling bling or some statistics on the git.git repository"
  http://thread.gmane.org/gmane.comp.version-control.git/88174

A short listing of metrics done:
* stats.py author -d: Shows file activity of a specific developer
  measured in how often they made a modification to a file and total
  lines added/removed (much like a diffstat, but now for a specific
  developer instead of one commit).
* stats.py author -f: Shows file activity of a specific file measured
  in how often they made a modification to a file, could be extended to
  also count changes like "author -d"
* stats.py branch -b: Shows which branch a specific file belongs to,
  for more information on this metric see below
* stats.py commit -v: Shows all commits that are reverted by the
  specified commit, will be extended to allow detection of partial
  reverts
* stats.py diff -e: Shows whether two specific commits introduce the
  same changes
* stats.py diff -e -n: ditto, but ignores what changes were made, only
  looks at the changed lines
* stats.py diff -e -i: ditto, but inverts the comparison, instead of
  comparing addition with addition and deletions with deletions, the
  additions of the first diff are compared with the deletions of the
  second diff, and vise versa. This way a revert is easily detected.
* stats.py index -t: Shows which commits touched the same paths as the
  staged changes


3. Gitweb caching
 
Student: Lea Wiemann
Mentor: John 'warthog' Hawley

Lea has chosen caching data and memcached as example (primary) caching 
engine, wrote Git::Repo object-oriented Perl interface to git, used
it in gitweb, and added caching to gitweb.

Additionally tests for old Git.pm (simple), Git::Repo and friends, and
Mechanize based gitweb test were added.  Mechanize tests detected a few
bugs in current gitweb code: using Git::Repo and adding caching didn't 
create any new errors.

Currently first round of patches were send, and second version 
incorporating comments from is in progress.  There is a test site
(live demo) up and running on one of the kernel.org machines:
  http://odin3.kernel.org/git-lewiemann/

You can find first version of patches in 'pu' branch.


4. Eclipse plugin push support
 
Student: Marek Zawirski
Mentor: Shawn O. Pearce

Thus far Marek has completed generation of packs, including delta
re-use from packs using either v1 or v2 index, including taking
advantage of the CRC inside the v2 index to accelerate a safe reuse.
This code permits jgit to write a valid pack.

The packing code does not (yet) search for a delta base, or create
a new delta for an undeltified object.  Packing loose objects packs
them as whole objects in the pack file, resulting in little to no
reduction over their loose object size.  This is not a limitation
of Java.  Marek and I simply decided that protocol support was more
important than really tight network transport at this point in time.

As a result of being able to create pack files Marek was able to
implement the client side of git-push for the native pack transfer
service, aka push over SSH, push to another local repository (by
forking 'git receive-pack') and push over anonymous git://.

Using Marek's pack generation code Shawn added support for push over
the dumb sftp:// and amazon-s3:// protocols, with the latter also
supporting transparent client side encryption.


5. git-merge builtin

Student: Miklos Vajna
Mentor: Johannes Schindelin

> In "What's cooking in git.git (topics)" Junio C Hamano wrote:
> 
>   It already is beginning to become clear what 1.6.0 will look like.
>   [...]
>   * git-merge will be rewritten in C.

It is already in git as 1c7b76b (Build in merge).  
In Documentation/RelNotes-1.6.0.txt you can find the following:
   "* git-merge has been reimplemented in C."
 

6. git-sequencer

Student: Stephan Beyer
Mentor: Christian Couder, Daniel Barkalow
 
It started with discussion over TODO file format:
  http://thread.gmane.org/gmane.comp.version-control.git/84230
 
Now there is prototype shell script implementation (which has some 
limitations because it is prototype) in "git sequencer prototype"
  http://thread.gmane.org/gmane.comp.version-control.git/86985
  http://thread.gmane.org/gmane.comp.version-control.git/88754

The latter thread includes migration of git-am, git-rebase, and 
interactive rebase to sequencer.  

> Stephan Beyer wrote:
>   I'm using sequencer-based git-am and git-rebase-i and also 
>   git-sequencer itself for around 2-3 weeks now. So, for me, it is
>   reality-proven [...]

There were some problems with sequencer based implementation of
"git am --rebasing", or sequencer based patch application driven
ordinary rebase, but I think there were resolved.

Stephen have started the builtin sequencer (but till now no patches
were sent to list: seems to be work in progress). 

Some performance benchmarks:
 * applying 45 patches with git-am 
   - 3 seconds using the original 
   - 8 seconds using the (scripted) sequencer-based one
 * rebasing 100 commits
   -  4.8 seconds using the original
   - 10.1 seconds using the (scripted) sequencer-based one
   -  1.7 seconds using builtin sequencer


SUMMARY:
========
From those projects, "git-merge builtin" did what it was meant to do 
already.  "Eclipse plugin push support" and "git-statistics" did 
minimum what it was meant to do already, and it looks like it would be 
finished before August 11.  "Gitweb caching" is after first round of 
patches, "git-sequencer" looks like already done; I don't know what is 
the state of "GitTorrent" project.

Please correct any mistakes in this summary / writeup.  Thanks in 
advance.
-- 
Jakub Narebski
Poland