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

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

[Jakub Narebski]

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.

(It would be, I guess, good preparation for GSoC 2008 mid-term 
evaluations, which according to GSoC 2008 timeline
  http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
are to take place July 7 -- July 14.)


1. GitTorrent (???)

Student: Joshua Roys
Mentor: Sam Vilain

There was short thread of me asking about project
  http://thread.gmane.org/gmane.comp.version-control.git/83611
where I got gittorrent mailing list (no activity at least according to 
list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL 
for project repo / gitweb... which is currently down, so I cannot check 
if there is anything here.

What is the status of this project, please?

http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")


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
but it was mainly theoretical thread

The git-stats repository at http://repo.or.cz/w/git-stats.git (gitweb) 
has some commits, but I don't remember any of them on git mailing list.
Not ready?


3. Gitweb caching

Student: Lea Wiemann
Mentor: John 'warthog' Hawley

Lea has chosen caching data and memcached as primary caching engine,
and is working on object layer on top of Git.pm, namely Git::Repo and 
friends, which will be used by gitweb.  If I understand correctly 
caching is to be done, or at least helped by this layer.

There were added tests for Git.pm (now in git.git I think) and Mechanize 
test for gitweb (which detected a few errors).

Is it correct?


4. Eclipse plugin push support (!)

Student: Marek Zawirski
Mentor: Shawn O. Pearce

I am not following egit/jgit development close enough, but if I remember 
correctly there is some code which provides very rudimentary support 
for native generation of simplified packs, and IIRC also for push over 
some protocols.

And there is push support over SFTP and (encrypted) Amazon S3...


5. git-merge builtin (!!!)

Student: Miklos Vajna
Mentor: Johannes Schindelin

Builtin merge, together with preparation patches, is now at n-th 
iteration, as shown in the "Build in merge" thread:
  http://thread.gmane.org/gmane.comp.version-control.git/86584

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.


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

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

-- 
Jakub Narebski
Poland

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

[David Symonds]

On Tue, Jul 8, 2008 at 10:27 AM, Jakub Narebski <jnareb@gmail.com> 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.

[.. snip ..]

> 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
> but it was mainly theoretical thread
>
> The git-stats repository at http://repo.or.cz/w/git-stats.git (gitweb)
> has some commits, but I don't remember any of them on git mailing list.
> Not ready?

Sverre is in the process of writing up a progress report for the Git
ML; expect it by the end of this week.



Dave.

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

[Stephan Beyer]

Hi,

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

That's a nice "summary".
Imho the prototype patchset needs some more review from others.
(Well, I think the
   http://thread.gmane.org/gmane.comp.version-control.git/86985
thread died in the last days, but I hope some responses will come and
also that Junio's patch for cherry-picking root commits will be
included. I try to be patient...) ;-)

You may also add a little note, that I have started the builtin sequencer,
but I cannot provide really big news here :-)

Thanks for your overall git GSoC engagement,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Junio C Hamano]

Stephan Beyer <s-beyer@gmx.net> writes:

> Imho the prototype patchset needs some more review from others.

Yes, very much.  Not just from others and not just from me.

> (Well, I think the
>    http://thread.gmane.org/gmane.comp.version-control.git/86985
> thread died in the last days, but I hope some responses will come and
> also that Junio's patch for cherry-picking root commits will be
> included. I try to be patient...) ;-)

Please don't be patient but actively re-review what you sent out.

I _really_ wanted to merge the basic bits and rewrite of "am" at least to
pu tonight, but I had to drop them after noticing that it does not seem to
handle --rebasing at all (it parses to set $rebasing but after that where
does that bit go?  bash completion wants to see rebasing or applying
markers in .dotest), which made it a non-starter especially I'll be
cooking the other ORIG_HEAD in 'next' as well.

About the "rewrite rebase to use sequencer" bits, because we've dropped
the older rebase-i change, I do not want your series to depend on it.

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

[Stephan Beyer]

Hi,

Junio C Hamano <gitster@pobox.com> wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
> > (Well, I think the
> >    http://thread.gmane.org/gmane.comp.version-control.git/86985
> > thread died in the last days, but I hope some responses will come and
> > also that Junio's patch for cherry-picking root commits will be
> > included. I try to be patient...) ;-)
> 
> Please don't be patient but actively re-review what you sent out.
> 
> I _really_ wanted to merge the basic bits and rewrite of "am" at least to
> pu tonight, but I had to drop them after noticing that it does not seem to
> handle --rebasing at all (it parses to set $rebasing but after that where
> does that bit go?

Yes, you are right that am --rebasing is a no-op.
That option was a little mystery to me, because it seemed to do nothing
special, but I'll check again (bash-completion etc) and do appropriate
changes.

> About the "rewrite rebase to use sequencer" bits, because we've dropped
> the older rebase-i change, I do not want your series to depend on it.

Yes, I made the mistake that I started developing on "next" and I did
not expect that js/rebase-i-sequencer could be dropped. (I somehow
expected the opposite, that it would be migrated to master some day.)

Then I wanted to make it work on master, and thought this is simply
done by removing the "additional features" (-f and -p option using extended
todo list), but then I noticed that master also has a -p which works
entirely different and I wanted to see that stuff on the list before
July 1st and I had no idea what the status of js/rebase-i-sequencer is.
So I just tried and sent that last patch to the list in that way.

But now I have a clear statement.

So I'm going to send a new patchset (also with an EXAMPLES section in 
the docs) to the list in a few days.

Big thanks for the feedback,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Jakub Narebski]

On Tue, 8 July 2008, Stephan Beyer wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> I _really_ wanted to merge the basic bits and rewrite of "am" at least to
>> pu tonight, but I had to drop them after noticing that it does not seem to
>> handle --rebasing at all (it parses to set $rebasing but after that where
>> does that bit go?
> 
> Yes, you are right that am --rebasing is a no-op.
> That option was a little mystery to me, because it seemed to do nothing
> special, but I'll check again (bash-completion etc) and do appropriate
> changes.

Undocumented option '--rebasing' to git-am is internal option changing
git-am behavior to be better used by git-rebase, namely it does not
change commit message even if it doesn't follow git commit message
convention, for example if it begins not with single line summary
of commit, separated by empty line, but by multi-line paragraph.
See also t/t3405-rebase-malformed.sh

Although I am not sure if when rebase is rewritten using git-sequencer
implementing "git am --rebasing" would be truly needed.  On the other
hand side it would be nice to have some _documented_ option which would
allow to git-am mail messages with commits not following git commit
messages convention...

-- 
Jakub Narebski
Poland

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

[Stephan Beyer]

Hi,

Jakub Narebski wrote:
> > Yes, you are right that am --rebasing is a no-op.
> > That option was a little mystery to me, because it seemed to do nothing
> > special, but I'll check again (bash-completion etc) and do appropriate
> > changes.
> 
> Undocumented option '--rebasing' to git-am is internal option changing
> git-am behavior to be better used by git-rebase, namely it does not
> change commit message even if it doesn't follow git commit message
> convention,

Ah yes, I've seen it now.
It is taking the commit message from the commit in the "From <commit> .*"
line, does *not* change it in any way and then applies the changes using
threeway merge.

Keeping that in mind what about dealing with --rebasing like that:
if --rebasing is given, git am simply generates
	pick <commit>
lines, instead of
	patch -3 -k <msg>
as it is now (and this is not enough, as it seems).

Does someone have strong objections against that?

Speed could be one point in the case that git-apply just works without
needing threeway-fallback, but in the case of the fallback this will be
slower than pick, I think. So I'd not value that too high, but perhaps
there are opinions against my view.
Perhaps I am missing another point, too?


The alternative for doing "pick" is teaching git-sequencer's "patch"
insn an option that emulates the --rebasing behavior.

For me this feels somehow unclean. But perhaps there are good reasons.

> for example if it begins not with single line summary
> of commit, separated by empty line, but by multi-line paragraph.
> See also t/t3405-rebase-malformed.sh

Well, I have a test script that runs
 for i in t0023* t3350* t340* t3901* t4014* t4150* t5520* t7402*
and I run that script before I do a commit and after I rebased.
And I ran the whole test suite before I posted the patchset to the list.
What I want to say is: t3405 did not fail with my --rebasing no-op.

That's perhaps one reason why I forgot about implementing --rebasing
correctly.

> Although I am not sure if when rebase is rewritten using git-sequencer
> implementing "git am --rebasing" would be truly needed.

I didn't want to touch that behavior for several reasons.

Of course, somehow I think that rebase and rebase-i should be merged,
calling sequencer directly, with the main difference that -i will
invoke an editor to allow editing of the TODO file.
But nobody is hurt, if I put such a change far far away.


Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Jakub Narebski]

Stephan Beyer wrote:
> Jakub Narebski wrote:

>>> Yes, you are right that am --rebasing is a no-op.
>>> That option was a little mystery to me, because it seemed to do nothing
>>> special, but I'll check again (bash-completion etc) and do appropriate
>>> changes.
>> 
>> Undocumented option '--rebasing' to git-am is internal option changing
>> git-am behavior to be better used by git-rebase, namely it does not
>> change commit message even if it doesn't follow git commit message
>> convention,
> 
> Ah yes, I've seen it now.
>
> It is taking the commit message from the commit in the "From <commit> .*"
> line, does *not* change it in any way and then applies the changes using
> threeway merge.

Not exactly.  "git am --rebasing" still tries to first just *apply*
the patch, then (I think) it falls back on blob-id based 3way merge.
 
> Keeping that in mind what about dealing with --rebasing like that:
> if --rebasing is given, git am simply generates
> 	pick <commit>
> lines, instead of
> 	patch -3 -k <msg>
> as it is now (and this is not enough, as it seems).

It is not.

Nevertheless it would be I think better for ordinary patch based rebase
to fall back not on git-am 3way merge, but on cherry-pick based merge
(i.e. on pick).

> The alternative for doing "pick" is teaching git-sequencer's "patch"
> insn an option that emulates the --rebasing behavior.
> 
> For me this feels somehow unclean. But perhaps there are good reasons.

Why unclean?

But I agree that it would be nice to simplify '--rebasing' logic, for
example using patch or 2way merge to generate tree, and commit message
taken directly from commit, not via 'format-patch | am' pipeline.
 
> Of course, somehow I think that rebase and rebase-i should be merged,
> calling sequencer directly, with the main difference that -i will
> invoke an editor to allow editing of the TODO file.
> But nobody is hurt, if I put such a change far far away.

rebase-m and rebase-i can be merged; ordinary rebase uses other
mechanism: git-am pipeline, and not cherry-picking.

-- 
Jakub Narebski
Poland

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

[Stephan Beyer]

Hi,

Jakub Narebski wrote:
> > It is taking the commit message from the commit in the "From <commit> .*"
> > line, does *not* change it in any way and then applies the changes using
> > threeway merge.
> 
> Not exactly.  "git am --rebasing" still tries to first just *apply*
> the patch, then (I think) it falls back on blob-id based 3way merge.

That's of course totaly right and what I've meant, but unfortunately not
what I've written ;-)

> > Keeping that in mind what about dealing with --rebasing like that:
> > if --rebasing is given, git am simply generates
> > 	pick <commit>
> > lines, instead of
> > 	patch -3 -k <msg>
> > as it is now (and this is not enough, as it seems).
> 
> It is not.
> 
> Nevertheless it would be I think better for ordinary patch based rebase
> to fall back not on git-am 3way merge, but on cherry-pick based merge
> (i.e. on pick).

Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
am --rebasing... But cherry-pick should only be chosen if a simple git-apply
failed first. Right?

I just got another idea which could easily be done and perhaps is the
right thing :)
Generating
	patch -C <commit> -3 <file>

This takes authorship and message from <commit> and does the usual
threeway-fallback behavior.

What do you think?

> But I agree that it would be nice to simplify '--rebasing' logic, for
> example using patch or 2way merge to generate tree, and commit message
> taken directly from commit, not via 'format-patch | am' pipeline.

That's right, but that would require me to hack around in git-rebase
which I tried to avoid for now. :)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Jakub Narebski]

Hi!

On Wed, 8 July 2008, Stephan Beyer wrote:
> Jakub Narebski wrote:
>> Stephan Beyer wrote:
>>>
>>> It is taking the commit message from the commit in the "From <commit> .*"
>>> line, does *not* change it in any way and then applies the changes using
>>> threeway merge.
>> 
>> Not exactly.  "git am --rebasing" still tries to first just *apply*
>> the patch, then (I think) it falls back on blob-id based 3way merge.
> 
> That's of course totaly right and what I've meant, but unfortunately not
> what I've written ;-)
> 
>>> Keeping that in mind what about dealing with --rebasing like that:
>>> if --rebasing is given, git am simply generates
>>> 	pick <commit>
>>> lines, instead of
>>> 	patch -3 -k <msg>
>>> as it is now (and this is not enough, as it seems).
>> 
>> It is not.
>> 
>> Nevertheless it would be I think better for ordinary patch based rebase
>> to fall back not on git-am 3way merge, but on cherry-pick based merge
>> (i.e. on pick).
> 
> Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
> am --rebasing... But cherry-pick should only be chosen if a simple git-apply
> failed first. Right?

Right.

> I just got another idea which could easily be done and perhaps is the
> right thing :)
> Generating
> 	patch -C <commit> -3 <file>
> 
> This takes authorship and message from <commit> and does the usual
> threeway-fallback behavior.
> 
> What do you think?

Very good idea (I have proposed something similar either here on in
another thread).  It would avoid some unnecessary "marshalling" and
"unmarshalling" which is needed to transfer commit message [unchanged]
through git-format-patch -> git-am pipeline, namely putting first
paragraph into subject line, generating then parsing RFC-2822 date,
using quoted printable encoding for first paragraph / subject header
(I think).

It would be still better to fallback to _pick_, not "git am --3way",
as the latter IIRC use _shortened_ _blob_ identifiers for pre- and
post-image to find common ancestor (merge base) for 3way merge.
Which is not necessary as we can find merge base and base commits
easier.

-- 
Jakub Narebski
Poland

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

[Lea Wiemann]

Jakub Narebski wrote:
> 3. Gitweb caching

I'll post a complete status update in the next few days.  And three
large patches (including the mechanize test). ;-)

> Lea has chosen caching data and memcached as primary caching engine,
> and is working on object layer on top of Git.pm, namely Git::Repo and 
> friends, which will be used by gitweb.  If I understand correctly 
> caching is to be done, or at least helped by this layer.

That's correct, except that I'm not using Git.pm anywhere; Git::Repo is
independent of Git.pm.  More about that later...

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

[J.H.]

>From a quick an cursory glance I think we are well on track with the
Gitweb stuff (though I'll let Lea do a full status update).  It looks
like most of the code is in place, and there is a test site up and
running on one of the kernel.org machines (though not anywhere near
production yet - I still need to port some of my other changes to Lea's
change set so we can try this out for real on Kernel.org)

- John 'Warthog9' Hawley

On Tue, 2008-07-08 at 06:08 +0200, Lea Wiemann wrote:
> Jakub Narebski wrote:
> > 3. Gitweb caching
> 
> I'll post a complete status update in the next few days.  And three
> large patches (including the mechanize test). ;-)
> 
> > Lea has chosen caching data and memcached as primary caching engine,
> > and is working on object layer on top of Git.pm, namely Git::Repo and 
> > friends, which will be used by gitweb.  If I understand correctly 
> > caching is to be done, or at least helped by this layer.
> 
> That's correct, except that I'm not using Git.pm anywhere; Git::Repo is
> independent of Git.pm.  More about that later...
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> 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.
> 
> (It would be, I guess, good preparation for GSoC 2008 mid-term 
> evaluations, which according to GSoC 2008 timeline
>   http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> are to take place July 7 -- July 14.)

Yes, it is that time for evaluations.  The evaluations are now open
to students and mentors alike; please make sure you complete them
by the deadline of July 14th.
 
> 4. Eclipse plugin push support (!)
> 
> Student: Marek Zawirski
> Mentor: Shawn O. Pearce
> 
> I am not following egit/jgit development close enough, but if I remember 
> correctly there is some code which provides very rudimentary support 
> for native generation of simplified packs, and IIRC also for push over 
> some protocols.
> 
> And there is push support over SFTP and (encrypted) Amazon S3...

Marek is on holiday right now, so I have to answer for him here.
Otherwise I would have preferred to let him do it.

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 I added support for push over
the dumb sftp:// and amazon-s3:// protocols, with the latter also
supporting transparent client side encryption.

I chose to add these features to jgit partly as an exercise to prove
that Marek's code was built well enough to be reused for this task,
partly because I wanted to backup some private personal repositories
to Amazon S3, and partly to prove that multiple dumb transports
could implement push support.

All of the above is done in the non-Eclipse, BSD licensed jgit
library, making it available to any tool built on top of the Java
platform, even if said tool does not use the Eclipse platform or
any other code from Eclipse.


At this point Marek's code is in the main egit.git tree's master
branch, and is in "production" use by myself and Robin, and maybe
a few others.  I am quite happy with the work Marek has completed
to date for the project.

When Marek returns from his holiday he will be working on Eclipse
UI features to expose this jgit push functionality to the end-user
within the Eclipse workbench.

-- 
Shawn.

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

[Joshua Roys]

Hello,

On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 1. GitTorrent (???)
>
> Student: Joshua Roys
> Mentor: Sam Vilain
>
> There was short thread of me asking about project
>  http://thread.gmane.org/gmane.comp.version-control.git/83611
> where I got gittorrent mailing list (no activity at least according to
> list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> for project repo / gitweb... which is currently down, so I cannot check
> if there is anything here.
>
> What is the status of this project, please?
>
> http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
>

It's going slower than I would like, in part due to a two-week period
when I was out of the country.  Other than that, it's going well, I
think.  Sam had a lot of the framework stuff done at the start, and
I've just been working my way through it.  My schedule has cleared up
for the remaining time, so things should move a little faster now.

The gitweb randomly gives 500/internal server errors, not sure why.

Joshua Roys

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

[Johannes Schindelin]

Hi,

On Tue, 8 Jul 2008, Joshua Roys wrote:

> Hello,
> 
> On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > 1. GitTorrent (???)
> >
> > Student: Joshua Roys
> > Mentor: Sam Vilain
> >
> > There was short thread of me asking about project
> >  http://thread.gmane.org/gmane.comp.version-control.git/83611
> > where I got gittorrent mailing list (no activity at least according to
> > list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> > for project repo / gitweb... which is currently down, so I cannot check
> > if there is anything here.
> >
> > What is the status of this project, please?
> >
> > http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
> >
> 
> It's going slower than I would like, in part due to a two-week period
> when I was out of the country.  Other than that, it's going well, I
> think.  Sam had a lot of the framework stuff done at the start, and
> I've just been working my way through it.  My schedule has cleared up
> for the remaining time, so things should move a little faster now.
> 
> The gitweb randomly gives 500/internal server errors, not sure why.

I thought you were working on the torrent stuff?  What is the status on 
that?

Ciao,
Dscho

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

[Jakub Narebski]

Johannes Schindelin wrote:
> On Tue, 8 Jul 2008, Joshua Roys wrote:
>> On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> 1. GitTorrent (???)

>>> There was short thread of me asking about project
>>>  http://thread.gmane.org/gmane.comp.version-control.git/83611
>>> where I got gittorrent mailing list [...] and URL
>>> for project repo / gitweb... which is currently down, so I cannot check
>>> if there is anything here.

[cut]
>> 
>> The gitweb randomly gives 500/internal server errors, not sure why.

(I think it was web server error, as error message didn't look like
it was coming from gitweb; besides gitweb up to some time ago didn't
use "500 Internal Server Error" HTTP error status code.)

> I thought you were working on the torrent stuff?  What is the status on 
> that?

I think Jushua was referring here to the fact that gitweb for
GitTorrent project repository[1] is sometimes down (it was down
when I was writing initial email in this thread).

[1] http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
-- 
Jakub Narebski
Poland

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

[Petr Baudis]

  Hi,

On Tue, Jul 08, 2008 at 12:31:45PM -0400, Joshua Roys wrote:
> On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > 1. GitTorrent (???)
> >
> > Student: Joshua Roys
> > Mentor: Sam Vilain
> >
> > There was short thread of me asking about project
> >  http://thread.gmane.org/gmane.comp.version-control.git/83611
> > where I got gittorrent mailing list (no activity at least according to
> > list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> > for project repo / gitweb... which is currently down, so I cannot check
> > if there is anything here.
> >
> > What is the status of this project, please?
> >
> > http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
> >
> 
> It's going slower than I would like, in part due to a two-week period
> when I was out of the country.  Other than that, it's going well, I
> think.  Sam had a lot of the framework stuff done at the start, and
> I've just been working my way through it.  My schedule has cleared up
> for the remaining time, so things should move a little faster now.
> 
> The gitweb randomly gives 500/internal server errors, not sure why.

  there's now a mirror at

	http://repo.or.cz/w/VCS-Git-Torrent.git

				Petr "Pasky" Baudis

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

[Sam Vilain]

Jakub Narebski wrote:
> 1. GitTorrent (???)
>
> Student: Joshua Roys
> Mentor: Sam Vilain
>
> There was short thread of me asking about project
>   http://thread.gmane.org/gmane.comp.version-control.git/83611
> where I got gittorrent mailing list (no activity at least according to 
> list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL 
> for project repo / gitweb... which is currently down, so I cannot check 
> if there is anything here.
>
> What is the status of this project, please?
>
> http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
>   

Hi, thanks for your interest.  I don't know when it was you checked - it 
may have been during a brief network outage our admins needed to do 
(unfortunately utsl.gen.nz is on a grace-and-favour service arrangement 
with its hosts, Catalyst), but the gitweb 
(http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent) is currently running, and 
I hope you can see the current activity.

I announced before that I would be sending an update shortly after the 
mid-term deadline, and I still plan on doing this.  Please be patient 
and wait until that happens in a week or so.

Cheers,
Sam.

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

[Sverre Rabbelier]

[Once again I forgot to "reply to all", sorry Jakub ;)]

Heya,

On Tue, Jul 8, 2008 at 2:27 AM, Jakub Narebski <jnareb@gmail.com> 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.

Would you like us to go to the wiki page and edit them ourselves, yes?
If so, I'll see about kicking up something interesting to put up there
soon.

> (It would be, I guess, good preparation for GSoC 2008 mid-term
> evaluations, which according to GSoC 2008 timeline
>  http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> are to take place July 7 -- July 14.)

Agreed.

> 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
> but it was mainly theoretical thread
>
> The git-stats repository at http://repo.or.cz/w/git-stats.git (gitweb)
> has some commits, but I don't remember any of them on git mailing list.
> Not ready?

I am not yet sure how I should send in my code for peer review.
$ git rev-list master | wc -l
151
A bunch of these patches introduce significant changes, a few are
fixes, and some are only changes to the changelog [0] which is
actually a pretty good way to see what I've been up to. Credit here
goes to David for suggesting I keep one. I am contemplating sending in
one patch per module since I've structured my code in such a way that
each module is mostly a stand-alone file that can be reviewed in
itself. I am not sure if there is any way to get such code reviewed,
most other projects had several distinct steps (e.g., modifying parts
of existing code first) they had to go through before they could write
new code. My project has been "new code" from the get go, so any
advice as to how to send this in for peer review is very welcome.

I have been working on GitStats, an attempt to gather metrics on a git
repository. For those who would like to know more about my goals,
please have a look at [1] or the more general [2]. Currently I have
quite a few metrics done, most of them are aimed at detecting whether
a commit is a bugfix. 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 meaured
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

I am working now on getting the 'is a bugfix' metric going, it's
sub-metrics are mostly done ('branch contains' , 'is revert', 'commit
msg matches', 'commit diff matches') with the exception of a few
simple ones ('is partial revert', 'modifies same lines') that are
already almost done. As a sneak peek into what I've been up to I'll
zoom in a bit on the development of the 'belongs to' metric.

One of the hardest things to tackle was the 'belongs to'
metric. It's goal is to determine how much a certain commit
'belongs to' a specific branch. When aggregating this
metric one can pick the best fit. This is useful when
trying to figure out if a commit was made on a maintenance
branch, and as such whether it should be marked as a 'fix'.
The definition of "belonging to" a branch was made as follows: "Each
branch that contains the target commit begins with a 'dilution' of 0,
for each merge on the way between it and the commit, increase the
dilution by one if it was not the primary parent of the merge. This
means that if a commit was "merged into" a branch instead of having
been made on that branch, it will have a higher dilution than if the
commit was made on that branch. This way, the lower the dilution, the
more a commit belongs on a branch.

The problem with this metric was not in writing it, but in
getting it to not be terribly slow on large repositories.
A few of the major problems include:
* Do not call git-rev-list on each commit, but instead
 gather all 'parentage' information beforehand. This
 avoids a lot of calls to the git binary, which is
 expensive. This simple optimization resulted in a huge
 speed increase, even on the small tests.
 With this in place it runs in under a second for the test
 repository, but the git.git repo still takes ages.
* Do not revisit commits that have already been checked
 _and had a lower or equal dilution_ in the previous
 check.
 Especially in the git.git repository this
 optimization made the algorithm go from 'unusable' to
 useful.
 With this in place it runs in under a second for recent
 commits. It takes under 20 seconds for the first commit
 in the repository.
* Keep a global memory too, that is, when multiple branches
 contain the commit, remember that we have already visited
 a commit in a global memory as well. When visiting
 a commit we check if we already visited it before but
 with a lower dilution, if so, this means that another
 branch is always going to be better than the current
 branch at this point, as such, we stop walking there.
 With this in place it still runs in under a second for
 recent commits. It takes about 7 seconds for the first
 commit in the repository.
* Do a rev-list on all branches we are interested in once,
 instead of once for each branch. In order to cut down the
 output by not listing 'subsets', the rev-lists of each
 individual branch was needed. By not doing this filtering
 a lot of time is saved.
 With this in place it still runs in under a second for
 recent commits. It takes a little over 5 seconds for the
 first commit in the repository.

The above timings were made on a rather outdated version of git.git,
after updating to today's latest the timings are as follows:

$ time stats.py branch -b e83c516331
Matching branches:
pu
next
master
maint
offcuts

real    0m6.360s
user    0m6.228s
sys     0m0.244s

It is plausible that there is no way to do this any faster
with the current approach. Walking all commits, examining
them, and calculating the dilution, all the way to the root
commit (on the git.git repo) just takes that long. The
algorithm itself is almost instant, most of the time is
spent waiting for git rev-list to return.

For a recent commit on the maint branch we can find the following
information (the -d flag was included to include 'debug' information,
so that we can see what other information was found, but left out in
the regular report):

sverre@Laptop-Sverre:~/code/git$ time stats.py branch -b 2b2828b -d
Retreiving branches that contain the commit...
Gathering information on the history...
Done.

Checking branches now:
origin/next
master
origin/maint
origin/pu
Done.

Listing found metrics:
Branch next, dilution: 2.
Branch master, dilution: 1.
Branch maint, dilution: 0.
Done.

Matching branches:
The minimal dilution is: 0
maint

real    0m6.431s
user    0m6.164s
sys     0m0.260s

>From the above one can see that master has recently merged in that
commit, but that next did not include it until after it merged in
master. In this way a commit can cascade through multiple merge, earch
merge increasing it's dilution by one.

I am very interested to hear comments on my progress so far, but also
on what is thought to be "important to work on next". It would be
awesome if a few people could give it a test drive. I recommend using
the setupRepo.py script in 'src/scripts' which will create a
metricsrepo in /tmp/ that is very well suited to experiment with the
'belongs to' metric. The testrepo also created in /tmp is better
suited to test some of the other metrics. Both repositories are used
by the testcases under 'src/t', which should all pass :). My
repository can be found at [3].

Thank you for reading, and I'm looking forward to review/comments.

[0] http://repo.or.cz/w/git-stats.git?a=blob;f=doc/changelog.txt
[1] http://alturin.googlepages.com/Use_cases.html
[2] http://alturin.googlepages.com/gsoc2008
[3] http://repo.or.cz/w/git-stats.git

--
Cheers,

Sverre Rabbelier

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

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Wed, Jul 09, 2008 at 12:18:41PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> I am not yet sure how I should send in my code for peer review.
> $ git rev-list master | wc -l
> 151

What I did squashing fixes regularly, but I keep a 'history' branch
where I always reference to the old HEAD, so others can still have a
look at the individual commits.

It's like:

$ cat rebase-builtin-merge.sh
#!/bin/sh -e

[ -n "$*" ]

old_head=$(git rev-parse HEAD)
git rebase $*
git update-ref refs/heads/rebase-history \
        $(echo "Rebased with 'git rebase $*'" | \
        git commit-tree HEAD^{tree} -p rebase-history -p $old_head -p HEAD)

It will not work properly if you get conflicts, but you got the idea.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Jakub Narebski]

On Wed, 9 July 2008, Sverre Rabbelier wrote:
> On Tue, Jul 8, 2008 at 2:27 AM, Jakub Narebski <jnareb@gmail.com> 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.
> 
> Would you like us to go to the wiki page and edit them ourselves, yes?

Yes, thanks in advance.

> If so, I'll see about kicking up something interesting to put up there
> soon.

I'd rather students or mentors did write short summary on mentioned
wiki page, but I'll try to come up with some short summary for each
GSoC2008 project (if it won't be there already) after July 14.


[thanks for summary]
-- 
Jakub Narebski
Poland

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

[Jakub Narebski]

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

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

[Sverre Rabbelier]

On Mon, Jul 21, 2008 at 12:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> 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.

I've been feeling guilty about not writing a summary yet, sorry for that :(.

> 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 bug -t: Calculates a 'score' for a specific commit,
representing how likely it is to be a bugfix. There are four metrics
used to determine this: "Commits x reverts another commit y", "Commit
x belongs to one of the specified branches (e.g., 'maint')", "The diff
for commit x contains a specific phrase", "The msg for commit x
contains a specific phrase". A rating can be given to each metric by
the user.
* stats.py bug -a: Aggregates the 'bug -t' metric over a range of
commits. The default is the last 10 commits on HEAD. This routine is
optimized to   not recalculate metrics/to not redo work   that was
already done in a 'bug -t' call for another commit. As such there is a
set setup time to determine the type of the first commit, after which
calculation time increases at a much lower pace. (So 'bug -a' on 10
commits might take 4 seconds, and running it over 11 commits might
take only 4.5".)

> * stats.py branch -b: Shows which branch a specific file belongs to,

a commit 'belongs to' a branch when the commit is made on that branch.

> * stats.py commit -v: Shows all commits that are reverted by the
>  specified commit, will be extended to allow detection of partial
>  reverts

This has been moved to 'diff -r'.

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

I think the rest is a nice summary of what I've been doing :).


> SUMMARY:
> ========
> [...] "git-statistics" did a minimum what it was meant to do already, and it looks like it would be finished before August 11. [..]

My deadline is August 1 since my vacation starts then and I can't work
during my vacation (all hail American tax laws), but David is
confident that I will have a finished product before then, and I plan
not to let him down on that expectation.

> Please correct any mistakes in this summary / writeup.

I tried to as best as I could :).

> Thanks in advance.

No, thank you! Thanks for writing up this summary, very nicely done.

-- 
Cheers,

Sverre Rabbelier

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

[Stephan Beyer]

Hi,

what you write is quite detailed :)

Jakub Narebski wrote:
> 6. git-sequencer
> 
[...]
> 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.

They were resolved, but there is a new problem that occured in the
am --abort thread of Junio: the sequencer-based git-am does not work
on dirty working tree.

I've also fixed some other minor issues and have not yet sent this to
the list (because I think I stumble over even more while writing the
builtin-sequencer.)

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

Right.

> 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

:)
I think I'm going to format-patch the same 100 test commits and then I
change the "applying 45 patches with git-am" part on the Wiki.

Regards.

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Sam Vilain]

On Mon, 2008-07-21 at 00:29 +0200, Jakub Narebski wrote:
> 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/

That's a valid complaint.  I've posted a summary of the project status
there, and will keep as much related discussion as appropriate on-list
from here.

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

git-log | git-shortlog?  ;)

Sam.

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

[Johannes Schindelin]

Hi,

On Mon, 21 Jul 2008, Sam Vilain wrote:

> On Mon, 2008-07-21 at 00:29 +0200, Jakub Narebski wrote:
> > 1. 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.
> 
> git-log | git-shortlog?  ;)

Please note that one of the reasons why last year's libgit-thin project 
has not been merged, or even been useful to anybody else, because it has 
been developed in too private a manner.  Sad.

I would appreciate it, therefore, to keep the progress way more public 
than it is now.  That is, either you or your student should be not 
invisible.

Ciao,
Dscho

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

[Jakub Narebski]

On Mon, 21 July 2008, Sam Vilain wrote:
> On Mon, 2008-07-21 at 00:29 +0200, Jakub Narebski wrote:
> >
> > 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/
> 
> That's a valid complaint.  I've posted a summary of the project status
> there, and will keep as much related discussion as appropriate on-list
> from here.

You can find it on GMane, too:
  http://thread.gmane.org/gmane.comp.version-control.git.gittorrent/1

It would be nice if it was send to git mailing list too, perhaps
directing replies to gittorrent mailing list only by default.

A short summary of this thread (please correct me if I am wrong):

 * Tracker: representing "metainfo" files, working tracker (test)
   is in progress

 * Core infrastructure: "Commit Reel" sorting algorithm implemented[1]
   B-tree index for fast querying.

   To be done is determining minimal set of edge objects which define
   reel (that can be passed to "git rev-list --objects-edge" to get thin
   pack representing reel).

 * Peer to Peer: handshake and two trivial messages[2] implemented.
   To be done are (minimally) "References", "Blocks", "Request" and
   "Play" messages.

Footnotes:
==========
[*1*] "the current implementation is quite slow (requiring two calls to
'git-cat-file' for each object)" <-- why you don't use '--batch' or
'--batch-check' options to git cat file: see also Git::Repo and friends
implementation send by Lea Wiemann to git mailing list as part of
"Gitweb caching" project?  BTW. by keeping discussion off the list,
you are off the knowledge of git community, too.

[*2*] _What_ are those "two trivial messages"?

-- 
Jakub Narebski
Poland

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

[Petr Baudis]

On Mon, Jul 21, 2008 at 12:23:45PM +0200, Jakub Narebski wrote:
> [*1*] "the current implementation is quite slow (requiring two calls to
> 'git-cat-file' for each object)" <-- why you don't use '--batch' or
> '--batch-check' options to git cat file: see also Git::Repo and friends
> implementation send by Lea Wiemann to git mailing list as part of
> "Gitweb caching" project?  BTW. by keeping discussion off the list,
> you are off the knowledge of git community, too.

I concur. Only now I realized that this project might be an important
Git Perl API user. Can you please reconsider having a separate mailing
list for discussions etc.? The traffic seems to be very low anyway, and
I'm not sure what benefits does it actually have at all.

				Petr "Pasky" Baudis

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

[Joshua Roys]

Petr Baudis wrote:
> On Mon, Jul 21, 2008 at 12:23:45PM +0200, Jakub Narebski wrote:
>> [*1*] "the current implementation is quite slow (requiring two calls to
>> 'git-cat-file' for each object)" <-- why you don't use '--batch' or
>> '--batch-check' options to git cat file: see also Git::Repo and friends
>> implementation send by Lea Wiemann to git mailing list as part of
>> "Gitweb caching" project?  BTW. by keeping discussion off the list,
>> you are off the knowledge of git community, too.
> 
> I concur. Only now I realized that this project might be an important
> Git Perl API user. Can you please reconsider having a separate mailing
> list for discussions etc.? The traffic seems to be very low anyway, and
> I'm not sure what benefits does it actually have at all.
> 
> 				Petr "Pasky" Baudis

Thank you for that suggestion!  I made it call cat-file only once in 
batch mode and it goes quite a bit faster now.

Josh

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

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> 1. GitTorrent
>  
> Student: Joshua Roys
> Mentor: Sam Vilain
...
> 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...)

Yes, this is the project I referred to in the podcast about going dark.
 
> 4. Eclipse plugin push support
>  
> Student: Marek Zawirski
> Mentor: Shawn O. Pearce
> 
> [...] Marek and I simply decided that protocol support was more
> important than really tight network transport at this point in time.

Correction, the "I" in "Marek and I" isn't Jakub, its Shawn.  This
is just an editing mistake due to copy and paste from earlier thread.
Apparently my original paragraph here was already a nice summary of
the projects decisions thus far.

I'm likely to be offline much of the rest of this week (I got lucky
and found an open access point just now) but Marek is actively
working on user interface for push support, and I think if he finds
the time is considering adding delta generation.  That will be a
lot more time consuming as I think he needs to go back to original
academic papers to learn an LCS algorithm and then implement that.

Copyright and licenses around libxdiff and delta-diff.c won't allow
us to directly port the diff code to Java and our BSD license.  No,
I don't want to start a BSD-GPL license war.  Our decision to go
BSD in jgit may be a thorn in our side in areas such as this, but it
is probably better for our long-term goals of working more directly
with the Eclipse Foundation and perhaps also the NetBeans folks.

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

I think this is a pretty good summary.  I want to go through the
mid-term evaluations and summarize those for the mailing list but
I have not had a chance to do that yet.  With network being spotty
for the rest of this week it probably won't happen until the weekend.

I think the quick summary is our students and our mentors think
their projects are going well.  Jakub's summary above suggests
very much the same thing.  Its hard to claim a GSoC project isn't
meeting its goals when the code is already merged, or is at least
under active patch review.  ;-)

-- 
Shawn.

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

[Sverre Rabbelier]

[Reply to all this time, instead of reply, thanks Jakub for poking me
about that.]

On Wed, Aug 13, 2008 at 21:57, Jakub Narebski <jnareb@gmail.com> wrote:
> 2. git-statistics
>
> Student: Sverre Rabbelier
> Mentor: David Symonds
>
> GitStat development is finished at least with respect to GSoC 2008, see
> http://thread.gmane.org/gmane.comp.version-control.git/90691 (for the
> tax reasons), although I guess its development will continue.

Yup, it will, although at the moment I am on vacation in the US, and
I'm having a hard time finding the time to do any coding at all. I
will try to send in a patch to add GitStats to /contrib sometime soon,
but between not having internet/little time, it could take a bit.

> Status: Finished, I think also accepted: what is left is to put it
> eventually in 'contrib/gitstat' or 'contrib/stats'

Aye, as said above, might take a bit, but I will submit that patch.

> Student retention: Sverre has said if I remember correctly that he wants
> to work on improving '--follow', which now works only for very simple
> histories, for GitStats to be better among others.

Yup, that is correct, I will work on that and on improving GitStats in
my free time.

--
Cheers,

Sverre Rabbelier

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

[Jakub Narebski]

Now that according to Google Summer of Code 2008 timeline
  http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
we are in the middle of the suggested 'pencils down' date (August 11 --
-- August 18), I and perhaps other on git mailing list would like
to know what is the current status of all git GSoC 2008 projects.
I think that writing it down would help GSoC manager and co-manager...

Below there are my impressions about state of various Git's Google
Summer of Code 2008 projects, in the sequence the are on Git Wiki
http://git.or.cz/gitwiki/SoC2008Projects (I guess it would be nice
to have final information there after final 'pencils down' date at
18 August 2008).

1. GitTorrent
 
Student: Joshua Roys
Mentor: Sam Vilain

If I remember correctly at midterm it was deemed to be somewhat late;
metainfo was done, tracker was in works, some core infrastructure
and beginnings of peer to peer:
  http://thread.gmane.org/gmane.comp.version-control.git.gittorrent/1

Unfortunately this project, even that is as much tied with git as StGIT,
or egit/jgit, or git-gui or gitk, all of which use git mailing list for 
discussion and patches, choose to have its own separate mailing list; 
moreover I think most of discussion was kept private.

Status: I have no idea how close GitTorrent is to completion (where by 
completion I mean ready, tested and benchmarked code running e.g. on 
kernel.org).  I'm not sure if it is meant to be incorporated in git, 
even in contrib, or remain separate like StGIT, TopGit or jgit.

Student retention: One of reasons in Git application for participating 
in GSoC was having "fresh blood", new long-time contributors.  I have 
vague notion that Joshua is quite active not only with GitTorrent, and 
would stay git contributor...


2. git-statistics

Student: Sverre Rabbelier
Mentor: David Symonds

GitStat development is finished at least with respect to GSoC 2008, see
http://thread.gmane.org/gmane.comp.version-control.git/90691 (for the 
tax reasons), although I guess its development will continue.  

Status: Finished, I think also accepted: what is left is to put it 
eventually in 'contrib/gitstat' or 'contrib/stats'

Student retention: Sverre has said if I remember correctly that he wants 
to work on improving '--follow', which now works only for very simple 
histories, for GitStats to be better among others.


3. Gitweb caching

Student: Lea Wiemann
Mentor: John 'warthog' Hawley

There are new tests for gitweb (to check if caching would not break 
anything new: it did caught a few breakages), new object Perl API to 
git, and gitweb caching implemented using caching data at the level 
slightly above calling git commands.  But full code (tests, Perl API 
and changes to gitweb) are only after first, maybe second round of 
review.  In short, it looks like it is 90% done, as in: "The first 
ninety percent of the task takes ninety percent of the time, and the 
last ten percent takes the other ninety percent."

There is a test site (live demo) up and running on one of the kernel.org 
machines:
  http://odin3.kernel.org/git-lewiemann/

Status: Seems to done, but: not yet merged in, neither used at 
kernel.org or repo.or.cz (i.e. not as fork of gitweb), and no 
benchmarks.

Student retention: unknown.


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

JGit can now create (suboptimal) packs: it can reuse delta, but cannot 
currently create one.  This is used to implement push support in 
jgit/egit.

Status: Done, merged in, and used as example to add for example Amazon's 
S3 support and SFTP transport support.

Student retention: I don't know, but I guess it is likely.


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.

Status: Done and merged in.
Student retention: Most likely.

 
6. git-sequencer

Student: Stephan Beyer
Mentor: Christian Couder, Daniel Barkalow

There was discussion about TODO file format, there is prototype shell 
script implementation, and reimplementing git-rebase--interactive and 
other using it; there is built-in sequencer done or almost done, but I 
don't remember it being sent to git mailing list for review.  
Benchmarks show performance improvements for built-in sequencer 
versions.

Status: AFAIK close to be done.  I don't know about it being merged-in.
Student retention: Likely.

-- 
Jakub Narebski
Poland

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

[Sam Vilain]

On Thu, 2008-08-14 at 04:57 +0200, Jakub Narebski wrote:
> 1. GitTorrent
>  
> Student: Joshua Roys
> Mentor: Sam Vilain
> 
> If I remember correctly at midterm it was deemed to be somewhat late;
> metainfo was done, tracker was in works, some core infrastructure
> and beginnings of peer to peer:
>   http://thread.gmane.org/gmane.comp.version-control.git.gittorrent/1
> 
> Unfortunately this project, even that is as much tied with git as
> StGIT,
> or egit/jgit, or git-gui or gitk, all of which use git mailing list
> for 
> discussion and patches, choose to have its own separate mailing list; 
> moreover I think most of discussion was kept private.
> 
> Status: I have no idea how close GitTorrent is to completion (where
> by 
> completion I mean ready, tested and benchmarked code running e.g. on 
> kernel.org).  I'm not sure if it is meant to be incorporated in git, 
> even in contrib, or remain separate like StGIT, TopGit or jgit.

The scope outlined in the GitTorrent proposal was a little bit more of a
research project; being ready for production use on kernel.org or having
code ready to merge to git was not directly a deliverable.

The approved idea at the outset of *this* project was to try out the RFC
protocol design as it stands, iron out the weaknesses and see how it
performs.  As it was pointed out along the way, there are other simpler
designs possible, but I tried to explain how the fully denormalized
design of the current RFC gives it more legs compared to other
approaches.  ie the goal was to prove the proposed network design, and
test it and show it to be as resource efficient as the more pragmatic
designs proposed by people like Johannes (or, indeed, earlier versions
from Jonas which were much closer to bittorrent in design).

I was certainly hoping that at or shortly after the end it would at that
point also be good enough to be useful for production sites, even
kernel.org sized (perhaps requiring the odd piece rewritten in C).  We
just need to crawl before we can walk, so to speak.

I think saying "we're on track to prove the protocol" might be a little
of an exaggeration at this point.  But we have got a test script that is
performing a replication between two test directories, transmitting data
over sockets using GTP.

Once Joshua has wrapped up this work to make it "less hackish" to
drive ;) then we can review the implementation and sign off on
completion of what was technically set out to complete.  At that point
the design becomes open to suggestions from the floor again.

Anyway, that's the current status at this time.  Thanks for the prod to
update, Jakub.  Come the actual completion date of the program, there
will be complete news.

Cheers,
Sam.

---
and now the rant:

Please bear in mind that some of the "why Didn't You Just..." type
comments are really "20/20 hindsight" now.  And please, comments about
what was made public and what not are also not useful.  The initial
design decisions between Jonas and myself are mostly in the RFC in
comments and in history from gittorrent.utsl.gen.nz.  Sure we chatted on
IRC about it here and there as well.  But the RFC has had a public
profile since at least last year's GSoC when our last student was
accepted to build it, but few people found time to comment on it.  I
have made every effort to keep everything useful in the public arena and
as far as I know never turned down the opportunity to answer questions.
And snide remarks about my choice to press a few buttons on my list
server to make a new mailing list for a project I was undertaking I
simply have no time for.

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

[Petr Baudis]

On Fri, Aug 15, 2008 at 12:42:23AM +1200, Sam Vilain wrote:
> I was certainly hoping that at or shortly after the end it would at that
> point also be good enough to be useful for production sites, even
> kernel.org sized (perhaps requiring the odd piece rewritten in C).  We
> just need to crawl before we can walk, so to speak.

FWIW, whenever you have any working code, let me know and I can deploy
it on repo.or.cz for some heavier testing. ;-)

				Petr "Pasky" Baudis

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

[Jakub Narebski]

On Thu, 14 Aug 2008, Sam Vilain wrote:
> On Thu, 2008-08-14 at 04:57 +0200, Jakub Narebski wrote:
>>
>> 1. GitTorrent
>>  
>> Student: Joshua Roys
>> Mentor: Sam Vilain
>> 
>> If I remember correctly at midterm it was deemed to be somewhat late;
>> metainfo was done, tracker was in works, some core infrastructure
>> and beginnings of peer to peer:
>>   http://thread.gmane.org/gmane.comp.version-control.git.gittorrent/1
[...]

>> Status: I have no idea how close GitTorrent is to completion (where by 
>> completion I mean ready, tested and benchmarked code running e.g. on 
>> kernel.org).  I'm not sure if it is meant to be incorporated in git, 
>> even in contrib, or remain separate like StGIT, TopGit or jgit.
> 
> The scope outlined in the GitTorrent proposal was a little bit more of a
> research project; being ready for production use on kernel.org or having
> code ready to merge to git was not directly a deliverable.
> 
> The approved idea at the outset of *this* project was to try out the RFC
> protocol design as it stands, iron out the weaknesses and see how it
> performs. [...]

That is a very good idea, but neither 
http://git.or.cz/gitwiki/SoC2008Projects#GitTorrent nor
http://code.google.com/soc/2008/git/appinfo.html?csaid=F544F0DAA82AFDFC
tells me that it is more about prototype implementation, or even
pre-prototype implementation (testing protocol design), than actually
implementing it in the state for it to be ready to use.

What I (and I guess also GSoC 2008 admins) would know is how far this
research on GitTorrent Protocol went; what milestones were achieved and
what were missed...

-- 
Jakub Narebski
Poland

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

[Johannes Schindelin]

Hi,

On Thu, 14 Aug 2008, Jakub Narebski wrote:

> 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.
> 
> Status: Done and merged in.
> Student retention: Most likely.

I could not put it better, IOW 'nuff said :-)

Ciao,
Dscho

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

[Lea Wiemann]

Jakub Narebski wrote:
> 3. Gitweb caching
> 
> Student: Lea Wiemann
> Mentor: John 'warthog' Hawley
> 
> There are new tests for gitweb (to check if caching would not break 
> anything new: it did caught a few breakages), new object Perl API to 
> git, and gitweb caching implemented using caching data at the level 
> slightly above calling git commands.  But full code (tests, Perl API 
> and changes to gitweb) are only after first, maybe second round of 
> review.

Correct.  I'm planning to post the next round of patches tonight or
tomorrow.  The remaining to-do items are:

1. We'll still have to have some discussion wrt. what to do about the
API and what status it should have -- Petr (and you as well?) complained
about missing command-line calling functionality.

2. I'll run benchmarks under various conditions, to measure how much
performance we gain with caching, and under what conditions it is most
beneficial.

3. Optional, but with some real performance benefits: Add support for
Last-Modified/If-Modified-Since.

4. Deploy on kernel.org (though John will have to do some/most of this,
and it'll take time beyond the pencils-down deadline I expect).

> Student retention: unknown.

Well, on the downside, I'm expecting to be pretty busy with college, so
there won't be much time to do substantial work on git or gitweb.  On
the upside, I feel perfectly comfortable with contributing to git (i.e.,
maintaining my own patch queue, sending patches, etc.), so it's very
much possible that at some point I'll be hacking git or gitweb again.

-- Lea

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

[Jakub Narebski]

On Fri, 15 August 2008, Lea Wiemann wrote:
> Jakub Narebski wrote:
> > 3. Gitweb caching
> > 
> > Student: Lea Wiemann
> > Mentor: John 'warthog' Hawley
> > 
> > There are new tests for gitweb (to check if caching would not break 
> > anything new: it did caught a few breakages), new object Perl API to 
> > git, and gitweb caching implemented using caching data at the level 
> > slightly above calling git commands.  But full code (tests, Perl API 
> > and changes to gitweb) are only after first, maybe second round of 
> > review.
> 
> Correct.  I'm planning to post the next round of patches tonight or
> tomorrow. [...]

Please remember that according to timeline in GSoC 2008 FAQ:
  http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
August 18: ~12 noon PDT / 19:00 UTC is "Firm 'pencils down' date."
(suggested pencils down date was August 11).  So you don't have much
time, and you don't leave much time for review, so I guess evaluation
would be "done, but nor merged in" or something like that.

> 2. I'll run benchmarks under various conditions, to measure how much
> performance we gain with caching, and under what conditions it is most
> beneficial.

And to compare with plain, vanilla gitweb, with kernel.org fork (both
performance and disk space used I guess) and repo.or.cz fork (only caches
projects list view, IIRC), I guess.

Benchmarking gitweb caching could be difficult, as you would have somehow
(fio?) replay conditions of I/O pressure as on kernel.org and repo.or.cz,
as from anegdotical evidence gitweb is IO bound, not CPU bound (so
ordinary speed benchmarks could give wrong results).

> > Student retention: unknown.
> 
> Well, on the downside, I'm expecting to be pretty busy with college, so
> there won't be much time to do substantial work on git or gitweb.  On
> the upside, I feel perfectly comfortable with contributing to git (i.e.,
> maintaining my own patch queue, sending patches, etc.), so it's very
> much possible that at some point I'll be hacking git or gitweb again.

It would be nice, even if you would be a "weekend contributor".

But I guess that making you into gitweb maintainer, or git.kernel.org
admin is out of the question... ;-)

-- 
Jakub Narebski
Poland

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

[Stephan Beyer]

Hi,

Jakub Narebski wrote:
> Please remember that according to timeline in GSoC 2008 FAQ:
>   http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> August 18: ~12 noon PDT / 19:00 UTC is "Firm 'pencils down' date."
> (suggested pencils down date was August 11).  So you don't have much
> time, and you don't leave much time for review, so I guess evaluation
> would be "done, but nor merged in" or something like that.

I'm wondering about "and you don't leave much time for review".
A comment on this:
LH (from the Google Open Source Team) clarified that the state of
Aug 18 is not the date where everything should be reviewed and merged
in.  It is the date where the (following) evaluation (done by the mentor)
of the code is based on.

See also
http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/df7278c6e027dee1

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Shawn O. Pearce]

Stephan Beyer <s-beyer@gmx.net> wrote:
> Jakub Narebski wrote:
> > Please remember that according to timeline in GSoC 2008 FAQ:
> >   http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> > August 18: ~12 noon PDT / 19:00 UTC is "Firm 'pencils down' date."
> > (suggested pencils down date was August 11).  So you don't have much
> > time, and you don't leave much time for review, so I guess evaluation
> > would be "done, but nor merged in" or something like that.
> 
> I'm wondering about "and you don't leave much time for review".
> A comment on this:
> LH (from the Google Open Source Team) clarified that the state of
> Aug 18 is not the date where everything should be reviewed and merged
> in.  It is the date where the (following) evaluation (done by the mentor)
> of the code is based on.
> 
> See also
> http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/df7278c6e027dee1

LH is correct.  A student doesn't have to get their code merged
just to have a successful project.  Perhaps the overall project is
in a frozen release candidate period and doesn't want to take _any_
new features until after the release is made.  That may be a full
month after the "pencils down" date.

Suppose even further that the project is on SVN, and has just one
branch, /trunk, such that even checking in the student's project
could break that release.

Clearly you cannot require the student to have their code merged
just to pass them.

However, I think it is reasonable to require that the student
has at least posted their patches for review and discussion, and
that the student has made a good-faith effort towards making those
patches something the community _might_ accept.  IOW it would be
good enough that Junio would consider slating it into "pu", even
though some final cleanup changes may be necessary.

-- 
Shawn.

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

[Jakub Narebski]

On Sat, 16 Aug 2008, Stephan Beyer wrote:

> Jakub Narebski wrote:
> >
> > Please remember that according to timeline in GSoC 2008 FAQ:
> >   http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> > August 18: ~12 noon PDT / 19:00 UTC is "Firm 'pencils down' date."
> > (suggested pencils down date was August 11).  So you don't have much
> > time, and you don't leave much time for review, so I guess evaluation
> > would be "done, but nor merged in" or something like that.
> 
> I'm wondering about "and you don't leave much time for review".

I mean here that we won't have time for a round of reviews and
corrections, it means that the code to be sent would be final
version to base GSoC evaluation.  No time for comments and corrections.

Built-in merge and push support for Eclipse went through many, many
cycles...

> A comment on this:
> LH (from the Google Open Source Team) clarified that the state of
> Aug 18 is not the date where everything should be reviewed and merged
> in.  It is the date where the (following) evaluation (done by the mentor)
> of the code is based on.

I agree that is a good idea.  Especially that project schedule (feature
freeze and like) not necesssary agree with GSoC timeline.

-- 
Jakub Narebski
Poland

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

[Marek Zawirski]

Jakub Narebski wrote:
> Now that according to Google Summer of Code 2008 timeline
>   http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> we are in the middle of the suggested 'pencils down' date (August 11 --
> -- August 18), I and perhaps other on git mailing list would like
> to know what is the current status of all git GSoC 2008 projects.
> I think that writing it down would help GSoC manager and co-manager...
(...)
> 4. Eclipse plugin push support
>  
> Student: Marek Zawirski
> Mentor: Shawn O. Pearce
> 
> JGit can now create (suboptimal) packs: it can reuse delta, but cannot 
> currently create one.  This is used to implement push support in 
> jgit/egit.
> 
> Status: Done, merged in, and used as example to add for example Amazon's 
> S3 support and SFTP transport support.

I'm just putting in the background patches with my 2nd big task for 
GSoC: (mostly) GUI for push. This code uses prior work - the one 
described by Jakub.

It took me a long time to do it, I was expecting some more time for 
other things, but it was probably better to focus on 1 thing at time. I 
think that we can say now that it's usable: it's possible to push from 
Eclipse in some (hopefully) sensible way.

Basing on created components, we can also add fetch GUI or remotes 
configuration editor easier than before.

> Student retention: I don't know, but I guess it is likely.

Nice guess! ;) That's quite true. I'm sure that I will no longer have 
that much time for coding jgit or egit, but when possible, I'll try to 
contribute in some way. Now, I'm starting to work on fetch GUI.

Having this opportunity, I want to say: thank you Shawn for being that 
great mentor! :) And thanks to other folks for given help. I've learned 
some new things here and it was (is?) nice experience to code for egit.

-- 
Marek Zawirski [zawir]
marek.zawirski@gmail.com

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

[Shawn O. Pearce]

Marek Zawirski <marek.zawirski@gmail.com> wrote:
>
>> Student retention: I don't know, but I guess it is likely.

Yea, I'm hoping Marek is going to be around for a bit.  He turned
into a really good contributor this summer.  Its been a pleasure
working with him on push support.

> Nice guess! ;) That's quite true. I'm sure that I will no longer have  
> that much time for coding jgit or egit, but when possible, I'll try to  
> contribute in some way. Now, I'm starting to work on fetch GUI.

Yay, fetch UI!  ;-)

-- 
Shawn.

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

[Joshua Roys]

Hello all.

As of today, here is the status of GitTorrent.  We can only transfer
repositories under extremely limited circumstances, which is not what
I would consider success, unfortunately.  I apologize for that.  I
would like to continue working on it, and other git things, in the
future though.  This was a really great experience, and in fact my
first actually working (closely) with the Open Source community.
Previously I had only sent in the random patch here and there.

A big 'thank you' to Sam Vilain and the other git folk who helped out.

For the curious that wish to look at the code:
http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent;a=summary
and a repo.or.cz mirror (since the above randomly fails):
http://repo.or.cz/w/VCS-Git-Torrent.git?a=shortlog

Joshua Roys

On Wed, Aug 13, 2008 at 10:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 1. GitTorrent
>
> Student: Joshua Roys
> Mentor: Sam Vilain
>
> Student retention: One of reasons in Git application for participating
> in GSoC was having "fresh blood", new long-time contributors.  I have
> vague notion that Joshua is quite active not only with GitTorrent, and
> would stay git contributor...
>

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

[Sam Vilain]

On Mon, 2008-08-18 at 21:25 -0400, Joshua Roys wrote:
> Hello all.
> 
> As of today, here is the status of GitTorrent.  We can only transfer
> repositories under extremely limited circumstances, which is not what
> I would consider success, unfortunately.  I apologize for that.  I
> would like to continue working on it, and other git things, in the
> future though.  This was a really great experience, and in fact my
> first actually working (closely) with the Open Source community.
> Previously I had only sent in the random patch here and there.
> 

Hi Joshua,

Thanks for saying this, it takes courage to face failure.

That being said, the code base is very close to the point where it can
be used to assess the success of the protocol design.  So while the GSoC
project is officially failed, I don't think we have to let the community
down.  Let's see if we can finish off the remaining bits and pieces and
put together such a report soon.

Cheers!
Sam.

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

[Stephan Beyer]

Hi,

Jakub Narebski wrote:
> 6. git-sequencer
> 
> Student: Stephan Beyer

The Google Open Source blog had an article about this thread[1]
and I noted that I forgot to inform you about my project here.

 1. http://google-opensource.blogspot.com/2008/08/git-and-google-summer-of-code.html

Until Sunday, Aug 17, I have been on testing, code cleanup and
bugfixing of the builtin-sequencer. Then I've sent this version
of the patchset to my mentors for a final review before the real
hard one (on the list *g*) and then I went away for three days.
That's perhaps why I forgot about this thread :)

That's also why there's not yet a patchset on the list.

I know there are a few people that already use (or at least used) the
(builtin) sequencer.  For the other curious people: the branches
"seq-builtin-dev" (development branch) or "seq-builtin-rfc" (rebased
patchset) on repo.or.cz[2] can be used, because I currently do not
know how long it will take until I send it to the list but I hope
it will be soon.

 2. http://repo.or.cz/w/git/sbeyer.git (seq-builtin-rfc, seq-builtin-dev)

(The last commit in seq-builtin-rfc is a test and I don't really like
it atm. It's reverted in the -dev branch.)

What else to say?
I will have not *much* time for git each day until the end of September
because of some other work and, especially, an important exam. But I
also try to take some time for git.
I also intend to keep contributing (at least small stuff) after the
builtin sequencer got into git. (I expect this is still some hard work
until the last one who has doubts is somehow satisfied.)

Kind regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F