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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
