GSoC 2008 - Mentors Wanted!

GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

As part of our organization application for GSoC 2008 we need to
list possible mentors.  At this stage of the process it is not a
binding commitment.  You can offer to be a mentor now and still
back out later if the project you are really interested in doesn't
get a student, or if your situation changes and you no longer will
have the time.

One of the things that will help make our organization application
look good to Google this year is having strong community support
for GSoC 2008, in the form of having many mentors available for
our ideas list.  Google can easily determine the size of our mailing
list membership (~859 addresses) and it would be nice if we can show
better than a 0.23% mentor rate.  :-)


Being a mentor will eventually become a binding commitment once we
start matching up students<->mentors and we know exactly how many
slots Google will offer us.  Backing out at this point could cause
us to scramble to locate another mentor, or worse, lose the student.
That gets set in stone during the week of April 7th - 11th, 2008.

Based on prior GSoC experience (inside and outside of Git) it
is estimated that a mentor will need to spend between 5-10 hours
per week (~1-2 hours per day) with their student, over email, IRC,
etc. to help guide the student through their project.  Projects run
from May 26th through August 11th.


OK, enough, onto the project list!

  http://git.or.cz/gitwiki/SoC2008Ideas

That is only a starting list of possible projects.  At present Dscho
and myself are listed as possible mentors for a vast majority of
these projects.  I'd love to get some more members of the community
involved this year.

If you are interested in being a mentor for a GSoC project, please
list your name next to the project, and if at all possible an email
address so prospective students can contact you.  If you have a good
project idea in mind, but don't see it on the wiki, please add it!

I would also appreciate it if you can send me your Google Mail
account, as we need to list each mentor's Google Mail username in
the organzation application.  This allows Google to see that we
have strong support for GSoC 2008, and gives you access to view
the student applications once they start getting submitted.

-- 
Shawn.

Re: GSoC 2008 - Mentors Wanted!

[Matthieu Moy]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> OK, enough, onto the project list!
>
>   http://git.or.cz/gitwiki/SoC2008Ideas

Jakub posted an idea about git.el (Emacs support) a few days ago:

> * GNU Emacs git GUI
>
>   Make git mode for Emacs full featured git GUI, and not only commit
>   tool, following ideas of PCL-CVS... and its limitation. I guess that
>   DVC (http://download.gna.org/dvc) git mode is one thing to examine
>   searching for features to implement, but from what I have read in
>   documentation it is quite a but GNU Arch centric. Other git GUIs, like
>   git-gui, gitk, qgit, tig could also be inspiration for features.
>
>   Goal: Allow creating and switching branches, examining history,
>   merging, fetching etc. from withing Emacs. Should include modes for
>   git config file forma and format-patch patches.
>
>   Language: Emacs Lisp
>   Suggested mentors:
>     Alexandre Julliard
>     David Kagedal

Since I've been quite involved in DVC in the past, I'm willing to help
with this, but unfortunately, I'm swamped with work and I can't commit
for ~5-10h/week on that.

So, if someone else steps in, perhaps we could rephrase the subject in
a "merge git.el and DVC, and improve it" way, and I could co-mentor
this one.

All that said, I think most of the ideas already on the wiki should be
prioritized (I love Emacs, but I think more people need a good Windows
support/GUI for example).

-- 
Matthieu

Re: GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Jakub posted an idea about git.el (Emacs support) a few days ago:
> > * GNU Emacs git GUI
> >
> >   Make git mode for Emacs full featured git GUI, and not only commit
> >   tool, following ideas of PCL-CVS... and its limitation. I guess that
> >   DVC (http://download.gna.org/dvc) git mode is one thing to examine
...
> 
> Since I've been quite involved in DVC in the past, I'm willing to help
> with this, but unfortunately, I'm swamped with work and I can't commit
> for ~5-10h/week on that.
> 
> So, if someone else steps in, perhaps we could rephrase the subject in
> a "merge git.el and DVC, and improve it" way, and I could co-mentor
> this one.

Thanks.  It would be nice to be able to have several mentors per
student project, to ease the burden on mentors.  But as you go
away from the core of git into the less widely used areas (e.g. I
am not an emacs user and thus do not touch the emacs git support)
its harder to find multiple mentors.  Then again, emacs users are
a friendly bunch so we might get lucky and have 5 emacs mentors. :)

> All that said, I think most of the ideas already on the wiki should be
> prioritized (I love Emacs, but I think more people need a good Windows
> support/GUI for example).

Yea.  But one thing I learned last year from GSoC was that students
are likely to come in one of three forms:

  Type a)  Just copy and paste our idea text.
           No thought on their part.

  Type b)  Actually think about our idea text and expand upon it.

  Type c)  Come up with their own really cool project idea.

Type c is what you really want, especially if the project idea
is well thought out by the student.  Type b is a close second.
Last year's students were all in this category.  Type a, well,
we had a number of type a applications last year.  Most orgs do.

In short, prioritizing this list doesn't really offer any great value
to us.  Not until we are actually faced with student applications
we like and we have to decide which ones get slots, and which don't.

-- 
Shawn.

Re: GSoC 2008 - Mentors Wanted!

[Jakub Narebski]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> That is only a starting list of possible projects.  At present Dscho
> and myself are listed as possible mentors for a vast majority of
> these projects.  I'd love to get some more members of the community
> involved this year.

I could be co-mentor for adding caching support to mainline gitweb.
I think I wouldn't have enough time for being full mentor;
additionally I don't know enough about HTTP / web caching to help.
I know gitweb fairly well, though.

I have CC-ed John 'Warthog9' Hawley (wrote caching for kernel.org's
gitweb), as a best candidate for mentor for this project, but I'm not
sure if he wouldn't be too busy for mentoring.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: GSoC 2008 - Mentors Wanted!

[Carlos Rica]

On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  OK, enough, onto the project list!
>
>   http://git.or.cz/gitwiki/SoC2008Ideas

Gitster talked today about libification as a project for the GSoC
(I mangled some comments, I accept complaints):

gitster> For the record, i've never said I am not interested in libification.

gitster> However.

gitster> (1) I know of many places whose design is based on
run-once-and-exit, and that was done for very good reasons (simpler
clean-up, no risk of reusing stale data, simpler codepath in general),
and

cehteh> gitster: yes anyone is interested .. i rather meant it would
be nice if you and others make it primary concern for accepting
patches/future development imo .. but well yes still your decision,
just a mild critic

* cehteh currently uses libgit and doesnt really feel comfortable with it

gitster> (2) cleaning up to make functions re-entrant can happen
incrementally, but should not have horrible performance issues for
run-once-and-exit users  --- see what we did to libify merge_base(),
for example, as that one is done the right way;

cehteh> yes

cehteh> we could even #ifdef LIBGIT or such for cleanup/reentrancy
stuff .. but someone has to lead supervise that, and others shouldent
throw bricks in the way which still sometimes happens

gitster> (3) and I know it would be a very large effort to do it all,
so a project that can be described with an umbrella "libification"
name would exceed GSoC size.

gitster> (4) and "should not" list in (2) includes maintainability.
Mindless #ifdefs are out.

gitster> So, I would not oppose it, but I just warn anybody that this
is a long term subproject.  I won't have time to commit myself on it,
unless everybody will be happy not to see any new developments merged
outside libification, that is.

gitster> So "libify merge-base" would have been a focused and well
defined subproject of GSoC size.  "libification" is not.

cehteh> ack

gitster> So was "libify the active_cache[] access".

gitster> "rewrite git-submodule, put the repository for submodules in
the superproject $GIT_DIR/modules, and use .git-file (currently in
'pu') to point at it", would be a good sized one.

gitster> "refine diffcore-rename to add a postprocessing phase so that
if we find rename from i386/foo.c to x86/foo.c but i386/bar.c was
rewritten too much and did not match new x86/bar.c make them match"
would be a good one as well.  Throw in "refine diffcore-rename further
so that it can tell a whole directory movement by summarizing the
constituent files' movement" and you will get a gold star ;-)

gitster> "teach 3-way fallback logic git-am has to git-apply".

....

Re: GSoC 2008 - Mentors Wanted!

[Carlos Rica]

On Tue, Mar 4, 2008 at 9:47 PM, Carlos Rica <jasampler@gmail.com> wrote:
>  Gitster talked today about libification as a project for the GSoC
>  (I mangled some comments, I accept complaints):

I mean, I removed some comments from the start, middle and end
of the conversation. The order and comments are left as it was.

--
Carlos

Re: GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

Carlos Rica <jasampler@gmail.com> wrote:
> On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >  OK, enough, onto the project list!
> >
> >   http://git.or.cz/gitwiki/SoC2008Ideas
> 
> Gitster talked today about libification as a project for the GSoC
> (I mangled some comments, I accept complaints):

Thanks for pasting this chunk of the log Carlos.  I otherwise would
have certainly missed it.  Much appreciated.
 
> gitster> For the record, i've never said I am not interested in libification.
> 
> gitster> However.

[... lots of good gitster remarks removed for space ...]

After some reflection I agree with Junio.  As such I have moved the
libification project down the page to a new category, "Projects So
Large Your Head Will Spin".

> gitster> "rewrite git-submodule, put the repository for submodules in
> the superproject $GIT_DIR/modules, and use .git-file (currently in
> 'pu') to point at it", would be a good sized one.
...
> gitster> "teach 3-way fallback logic git-am has to git-apply".

These have gone onto the list as smaller, more average sized
projects.  Both are interesting and useful.  Thanks Junio.

-- 
Shawn.

Re: GSoC 2008 - Mentors Wanted!

[Imran M Yousuf]

I would like to suggest 2 projects that I want to work as a developer
(and/or mentor):

1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
The aim of the plugin is to integrate GIT with NetBeans using JNI so
that any change in the implementation of GIT does not effect the SCM
plugins way of work.
Language: Java
Goal: Make GIT available from IDE for NetBeans users and use GIT using
Java Native Interfaces

2. distributed versioned web system backup and restoration framework
(GPLv2 with CPE, same as NetBeans)
[I am not sure whether this one is even qualifies or not as a GIT
Community Project]
Language: Java, NetBeans RCP
Goal: Develop a framework which can backup and restore data from
different components of web application. For example, database, ldap,
log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
allow edit and propagation of configuration in distributed nature,
system restart, data restore. Also integrate backup and repo maintain
to Amazon S3.

I would be grateful if others would express their opinion about them.

Thank you and best regards,

Imran

On Wed, Mar 5, 2008 at 11:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Carlos Rica <jasampler@gmail.com> wrote:
>
> > On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  > >  OK, enough, onto the project list!
>  > >
>  > >   http://git.or.cz/gitwiki/SoC2008Ideas
>  >
>  > Gitster talked today about libification as a project for the GSoC
>  > (I mangled some comments, I accept complaints):
>
>  Thanks for pasting this chunk of the log Carlos.  I otherwise would
>  have certainly missed it.  Much appreciated.
>
>
>  > gitster> For the record, i've never said I am not interested in libification.
>  >
>  > gitster> However.
>
>  [... lots of good gitster remarks removed for space ...]
>
>  After some reflection I agree with Junio.  As such I have moved the
>  libification project down the page to a new category, "Projects So
>  Large Your Head Will Spin".
>
>
>  > gitster> "rewrite git-submodule, put the repository for submodules in
>  > the superproject $GIT_DIR/modules, and use .git-file (currently in
>  > 'pu') to point at it", would be a good sized one.
>  ...
>
> > gitster> "teach 3-way fallback logic git-am has to git-apply".
>
>  These have gone onto the list as smaller, more average sized
>  projects.  Both are interesting and useful.  Thanks Junio.
>
>  --
>  Shawn.
>
>
> --
>  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
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557

Re: GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

Imran M Yousuf <imyousuf@gmail.com> wrote:
> 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
> The aim of the plugin is to integrate GIT with NetBeans using JNI so
> that any change in the implementation of GIT does not effect the SCM
> plugins way of work.
> Language: Java
> Goal: Make GIT available from IDE for NetBeans users and use GIT using
> Java Native Interfaces

Interesting, but libgit.a is *not* suitable for embedding inside of
a JVM.  Its no fun when a low level Git function suddenly calls die()
because it was fed invalid user input like a mistyped branch name.
Your whole IDE shutsdown without a chance to save files.

So that leaves you with three possible routes:

  * Use JNI and libgit.a

    Now you have three projects, not one.  You first need to make
    libgit.a embeddable.  *Then* you can work on a JNI wrapper,
    and finally you can build the UI.

  * Use jgit

    Its at least 100% pure Java and doesn't have the libgit.a issues
    I mentioned above.  Its also got some active developers and its
    userbase is growing.  We have been careful to keep jgit such
    that it runs on any J2SE system, and thus does not require an
    Eclipse environment.

  * Use java.lang.Process and pipes

    Ick.  Forking a running JVM, especially one the size of an IDE,
    is not pretty.  At least on Windows you have CreateProcess(),
    but on POSIX systems the JVM still does a fork/exec pair, and
    on Solaris that hurts hard when your address space is large.

Of these only the latter two are really viable for any time to come
(just my opinion, but that's that).  jgit is coming along and may
actually be able to do most of the critical features that an IDE
demands, especially if more people work on it.  The latter option
is obviously available today, but doesn't offer anything near the
performance or integration that jgit does.
 
> 2. distributed versioned web system backup and restoration framework
> (GPLv2 with CPE, same as NetBeans)
> [I am not sure whether this one is even qualifies or not as a GIT
> Community Project]
> Language: Java, NetBeans RCP
> Goal: Develop a framework which can backup and restore data from
> different components of web application. For example, database, ldap,
> log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
> allow edit and propagation of configuration in distributed nature,
> system restart, data restore. Also integrate backup and repo maintain
> to Amazon S3.

Yea, I'm not sure this falls too well under the Git community either.
I don't doubt that we would have sufficient mentor experience here
to support such a project, but the outcome in terms of both code and
a student who is familiar with it would not benefit Git very well,
if at all.
 
-- 
Shawn.

Re: GSoC 2008 - Mentors Wanted!

[Imran M Yousuf]

On Wed, Mar 5, 2008 at 2:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Imran M Yousuf <imyousuf@gmail.com> wrote:
>  > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
>  > The aim of the plugin is to integrate GIT with NetBeans using JNI so
>  > that any change in the implementation of GIT does not effect the SCM
>  > plugins way of work.
>  > Language: Java
>  > Goal: Make GIT available from IDE for NetBeans users and use GIT using
>  > Java Native Interfaces
>
>  Interesting, but libgit.a is *not* suitable for embedding inside of
>  a JVM.  Its no fun when a low level Git function suddenly calls die()
>  because it was fed invalid user input like a mistyped branch name.
>  Your whole IDE shutsdown without a chance to save files.
>
>  So that leaves you with three possible routes:
>
>   * Use JNI and libgit.a
>
>     Now you have three projects, not one.  You first need to make
>     libgit.a embeddable.  *Then* you can work on a JNI wrapper,
>     and finally you can build the UI.
>
>   * Use jgit
>
>     Its at least 100% pure Java and doesn't have the libgit.a issues
>     I mentioned above.  Its also got some active developers and its
>     userbase is growing.  We have been careful to keep jgit such
>     that it runs on any J2SE system, and thus does not require an
>     Eclipse environment.
>
>   * Use java.lang.Process and pipes
>
>     Ick.  Forking a running JVM, especially one the size of an IDE,
>     is not pretty.  At least on Windows you have CreateProcess(),
>     but on POSIX systems the JVM still does a fork/exec pair, and
>     on Solaris that hurts hard when your address space is large.
>
>  Of these only the latter two are really viable for any time to come
>  (just my opinion, but that's that).  jgit is coming along and may
>  actually be able to do most of the critical features that an IDE
>  demands, especially if more people work on it.  The latter option
>  is obviously available today, but doesn't offer anything near the
>  performance or integration that jgit does.
>

To start with I was actually thinking of JNI + "exec from C". So later
when libification is completed we can replace the execs with call to
the libs directly instead. Is this a viable fourth option (sorry I
forgot to mention it the first time around)?

>
>  > 2. distributed versioned web system backup and restoration framework
>  > (GPLv2 with CPE, same as NetBeans)
>  > [I am not sure whether this one is even qualifies or not as a GIT
>  > Community Project]
>  > Language: Java, NetBeans RCP
>  > Goal: Develop a framework which can backup and restore data from
>  > different components of web application. For example, database, ldap,
>  > log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
>  > allow edit and propagation of configuration in distributed nature,
>  > system restart, data restore. Also integrate backup and repo maintain
>  > to Amazon S3.
>
>  Yea, I'm not sure this falls too well under the Git community either.
>  I don't doubt that we would have sufficient mentor experience here
>  to support such a project, but the outcome in terms of both code and
>  a student who is familiar with it would not benefit Git very well,
>  if at all.
>
>  --
>  Shawn.
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557

Re: GSoC 2008 - Mentors Wanted!

[Imran M Yousuf]

On Wed, Mar 5, 2008 at 2:25 PM, Imran M Yousuf <imyousuf@gmail.com> wrote:
>
> On Wed, Mar 5, 2008 at 2:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  > Imran M Yousuf <imyousuf@gmail.com> wrote:
>  >  > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
>  >  > The aim of the plugin is to integrate GIT with NetBeans using JNI so
>  >  > that any change in the implementation of GIT does not effect the SCM
>  >  > plugins way of work.
>  >  > Language: Java
>  >  > Goal: Make GIT available from IDE for NetBeans users and use GIT using
>  >  > Java Native Interfaces
>  >
>  >  Interesting, but libgit.a is *not* suitable for embedding inside of
>  >  a JVM.  Its no fun when a low level Git function suddenly calls die()
>  >  because it was fed invalid user input like a mistyped branch name.
>  >  Your whole IDE shutsdown without a chance to save files.
>  >
>  >  So that leaves you with three possible routes:
>  >
>  >   * Use JNI and libgit.a
>  >
>  >     Now you have three projects, not one.  You first need to make
>  >     libgit.a embeddable.  *Then* you can work on a JNI wrapper,
>  >     and finally you can build the UI.
>  >
>  >   * Use jgit
>  >
>  >     Its at least 100% pure Java and doesn't have the libgit.a issues
>  >     I mentioned above.  Its also got some active developers and its
>  >     userbase is growing.  We have been careful to keep jgit such
>  >     that it runs on any J2SE system, and thus does not require an
>  >     Eclipse environment.
>  >
>  >   * Use java.lang.Process and pipes
>  >
>  >     Ick.  Forking a running JVM, especially one the size of an IDE,
>  >     is not pretty.  At least on Windows you have CreateProcess(),
>  >     but on POSIX systems the JVM still does a fork/exec pair, and
>  >     on Solaris that hurts hard when your address space is large.
>  >
>  >  Of these only the latter two are really viable for any time to come
>  >  (just my opinion, but that's that).  jgit is coming along and may
>  >  actually be able to do most of the critical features that an IDE
>  >  demands, especially if more people work on it.  The latter option
>  >  is obviously available today, but doesn't offer anything near the
>  >  performance or integration that jgit does.
>  >
>
>  To start with I was actually thinking of JNI + "exec from C". So later
>  when libification is completed we can replace the execs with call to
>  the libs directly instead. Is this a viable fourth option (sorry I
>  forgot to mention it the first time around)?
>

Just wanted to add that we can also make them 2 separate projects and
the reason I wanted to go with JNI is to take advantage of the new
developments of GIT without having to change the API (unless a new
release of the API all together).

>
>  >
>  >  > 2. distributed versioned web system backup and restoration framework
>  >  > (GPLv2 with CPE, same as NetBeans)
>  >  > [I am not sure whether this one is even qualifies or not as a GIT
>  >  > Community Project]
>  >  > Language: Java, NetBeans RCP
>  >  > Goal: Develop a framework which can backup and restore data from
>  >  > different components of web application. For example, database, ldap,
>  >  > log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
>  >  > allow edit and propagation of configuration in distributed nature,
>  >  > system restart, data restore. Also integrate backup and repo maintain
>  >  > to Amazon S3.
>  >
>  >  Yea, I'm not sure this falls too well under the Git community either.
>  >  I don't doubt that we would have sufficient mentor experience here
>  >  to support such a project, but the outcome in terms of both code and
>  >  a student who is familiar with it would not benefit Git very well,
>  >  if at all.
>  >
>  >  --
>  >  Shawn.
>  >
>
>
>
>
>
> --
>  Imran M Yousuf
>  Entrepreneur & Software Engineer
>  Smart IT Engineering
>  Dhaka, Bangladesh
>  Email: imran@smartitengineering.com
>  Mobile: +880-1711402557
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557

Re: GSoC 2008 - Mentors Wanted!

[Noel Grandin]

Imran M Yousuf wrote:
> To start with I was actually thinking of JNI + "exec from C". So later
> when libification is completed we can replace the execs with call to
> the libs directly instead. Is this a viable fourth option (sorry I
> forgot to mention it the first time around)?
>
>   

This is probably a good idea. JGIT is always going to be 2 steps behind
the native GIT code when comes to accessing on-disk structures.

This is also how the subversion plugin for the Eclipse IDE worked in the
beginning and the performance seemed to be acceptable (to me).

Regards, Noel.

Disclaimer: http://www.peralex.com/disclaimer.html

Re: GSoC 2008 - Mentors Wanted!

[Johannes Schindelin]

Hi,

On Wed, 5 Mar 2008, Noel Grandin wrote:

> Imran M Yousuf wrote:
> > To start with I was actually thinking of JNI + "exec from C". So later
> > when libification is completed we can replace the execs with call to
> > the libs directly instead. Is this a viable fourth option (sorry I
> > forgot to mention it the first time around)?
> >
> >   
> 
> This is probably a good idea. JGIT is always going to be 2 steps behind
> the native GIT code when comes to accessing on-disk structures.

Well, if you go the JNI route, you will always be platform dependent.  IMO 
this is one of the lesser intelligent things to do when relying on Java.

> This is also how the subversion plugin for the Eclipse IDE worked in the 
> beginning and the performance seemed to be acceptable (to me).

Git is much faster than subversion, so you will feel the overhead of 
fork()ing, especially on Windows.

Ciao,
Dscho

Re: GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

Noel Grandin <noel@peralex.com> wrote:
> Imran M Yousuf wrote:
> > To start with I was actually thinking of JNI + "exec from C". So later
> > when libification is completed we can replace the execs with call to
> > the libs directly instead. Is this a viable fourth option (sorry I
> > forgot to mention it the first time around)?
> 
> This is probably a good idea. JGIT is always going to be 2 steps behind
> the native GIT code when comes to accessing on-disk structures.

I'm not sure that is really going to be a major issue.

Thus far the Git on disk structure has been very stable over time.
We are 3 years old and yet have had very few file format changes,
and we are basically still backwards compatible.

The only new major on disk structure that JGit didn't support was
pack index v2, which I just taught JGit to parse tonight.  So yea,
we are a few months behind the bleeding edge on disk format, but
we are caught up again.
 
-- 
Shawn.

Re: GSoC 2008 - Mentors Wanted!

[Robin Rosenberg]

Den Wednesday 05 March 2008 08.58.15 skrev Imran M Yousuf:
> I would like to suggest 2 projects that I want to work as a developer
> (and/or mentor):
>
> 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
> The aim of the plugin is to integrate GIT with NetBeans using JNI so
> that any change in the implementation of GIT does not effect the SCM
> plugins way of work.
> Language: Java
> Goal: Make GIT available from IDE for NetBeans users and use GIT using
> Java Native Interfaces

As the current acting maintainer or egit/jgit I would not mind cooperating 
with making it available to Netbeans, J2EE and command line interface or
whatever.

You can make a plugin for Netbeans today that will do the basic like walking 
the history, finding out what to commit, commit, switch/create/reset 
branches, decorations based on jgit and you wouldn't need to change a thing 
in jgit. There might be things you *want* to change, but that's another story 
and applied to the continued development for the Eclipse plugin too. Even
the license might be changed.

You will find support in jgit for this today. Cloning over git and ssh real 
soon. I'm clensing the oopses from the history right now. (bless rebase -i
and git-gui).

There are no dependencies on Eclipse and I do not plan on introducing any.
Jgit and Egit live in the same repo at the moment simply because there are
no other users of egit so far.

There might be some operations that might be harder to do well in Java. For 
those exec'ing might be the solution, I'm thinking repack, but then I haven't 
tried it yet. In general jgit is almost as fast as git and probably 
outperforms git on windows as git there doesn't use  memory mapped I/O for 
packs (something I'd expect someone or even me to fix soon). For JNI'ed 
operations the complexity is just horrible and even when possible, there is
a lot of overhead for JNI itselt, conversion from UTF-16 to somehing 
eightbitish and back. On windows there's even yet another layer of 
eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
mapped I/O on all platforms that support it for pack reading.

If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
opinions differently.

-- robin

Re: GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> 
> You will find support in jgit for this today. Cloning over git and ssh real 
> soon. I'm clensing the oopses from the history right now. (bless rebase -i
> and git-gui).

I'm sort of waiting to see this fetch history soon.  :-)

The reason is I just got index v2 support (runtime read side) completed
and I want to add index v2 generation to IndexPack.  I also want to start
building a PackWriter so we can work on native transport push over SSH.

If we get fetch/push running I think we are heading into the area
where it is of some real use to people.
 
> There might be some operations that might be harder to do well in Java. For 
> those exec'ing might be the solution, I'm thinking repack, but then I haven't 
> tried it yet.

I'm determined to even get "proper" packfile generation in Java.
But it may be time consuming to build.  There may be license issues
around doing a direct cribbed port of the delta generation.  :-\

> In general jgit is almost as fast as git and probably 
> outperforms git on windows as git there doesn't use  memory mapped I/O for 
> packs (something I'd expect someone or even me to fix soon). For JNI'ed 
> operations the complexity is just horrible and even when possible, there is
> a lot of overhead for JNI itselt, conversion from UTF-16 to somehing 
> eightbitish and back. On windows there's even yet another layer of 
> eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
> mapped I/O on all platforms that support it for pack reading.
> 
> If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
> opinions differently.

Really?  If jgit is basically as fast as C git, but doesn't have
the overheads of dropping in and out of JNI or fork/exec then you
can actually get pretty good performance out of a Java application.

I've never really liked doing JNI.  I try to avoid it whenever
I possibly can.  JVMs just don't seem to be all that happy about
loading other native code into them, but yet they can do some very
good optimizations when everything is 100% pure Java and the JIT
has free reign to do what it pleases.

-- 
Shawn.

Re: GSoC 2008 - Mentors Wanted!

[Imran M Yousuf]

On Thu, Mar 6, 2008 at 11:08 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>  >
>  > You will find support in jgit for this today. Cloning over git and ssh real
>  > soon. I'm clensing the oopses from the history right now. (bless rebase -i
>  > and git-gui).
>
>  I'm sort of waiting to see this fetch history soon.  :-)
>
>  The reason is I just got index v2 support (runtime read side) completed
>  and I want to add index v2 generation to IndexPack.  I also want to start
>  building a PackWriter so we can work on native transport push over SSH.
>
>  If we get fetch/push running I think we are heading into the area
>  where it is of some real use to people.
>

It is great to hear this news :).

>
>  > There might be some operations that might be harder to do well in Java. For
>  > those exec'ing might be the solution, I'm thinking repack, but then I haven't
>  > tried it yet.
>
>  I'm determined to even get "proper" packfile generation in Java.
>  But it may be time consuming to build.  There may be license issues
>  around doing a direct cribbed port of the delta generation.  :-\
>
>
>  > In general jgit is almost as fast as git and probably
>  > outperforms git on windows as git there doesn't use  memory mapped I/O for
>  > packs (something I'd expect someone or even me to fix soon). For JNI'ed
>  > operations the complexity is just horrible and even when possible, there is
>  > a lot of overhead for JNI itselt, conversion from UTF-16 to somehing
>  > eightbitish and back. On windows there's even yet another layer of
>  > eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
>  > mapped I/O on all platforms that support it for pack reading.
>  >
>  > If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
>  > opinions differently.
>
>  Really?  If jgit is basically as fast as C git, but doesn't have
>  the overheads of dropping in and out of JNI or fork/exec then you
>  can actually get pretty good performance out of a Java application.
>
>  I've never really liked doing JNI.  I try to avoid it whenever
>  I possibly can.  JVMs just don't seem to be all that happy about
>  loading other native code into them, but yet they can do some very
>  good optimizations when everything is 100% pure Java and the JIT
>  has free reign to do what it pleases.

I personally too avoid JNI whenever possible; the only reason I was
even thinking of JNI in the first place is just to keep in touch with
the latest developments of jGit. But seeing the enthusiasm of the
community to contribute in developing a 100% Pure Java Git, I will
also participate in development of jGit; I think if we can get it to
do the regular operations we can generate enough interest to get a
community to regular keep it in sync with git.

>
>  --
>  Shawn.
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557

Re: GSoC 2008 - Mentors Wanted!

[Johannes Schindelin]

Hi,

On Thu, 6 Mar 2008, Shawn O. Pearce wrote:

> I'm determined to even get "proper" packfile generation in Java.

That's nice!

> But it may be time consuming to build.  There may be license issues 
> around doing a direct cribbed port of the delta generation.  :-\

I am sure a little mail to Nico will give you that license.

Ciao,
Dscho

Re: GSoC 2008 - Mentors Wanted!

[Robin Rosenberg]

Den Thursday 06 March 2008 06.08.46 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > You will find support in jgit for this today. Cloning over git and ssh
> > real soon. I'm clensing the oopses from the history right now. (bless
> > rebase -i and git-gui).
>
> I'm sort of waiting to see this fetch history soon.  :-)
>
> The reason is I just got index v2 support (runtime read side) completed
> and I want to add index v2 generation to IndexPack.  I also want to start
> building a PackWriter so we can work on native transport push over SSH.
>
> If we get fetch/push running I think we are heading into the area
> where it is of some real use to people.
>
> > There might be some operations that might be harder to do well in Java.
> > For those exec'ing might be the solution, I'm thinking repack, but then I
> > haven't tried it yet.
>
> I'm determined to even get "proper" packfile generation in Java.
> But it may be time consuming to build.  There may be license issues
> around doing a direct cribbed port of the delta generation.  :-\

If you know where to look, you might find a version of it. :) I don't think
I've changed so much as to prevent you from starting to code the push
part.

> > If someone *did* make a fully reentrant libgit, I'd be inclined to
> > balance my opinions differently.
>
> Really?  If jgit is basically as fast as C git, but doesn't have
> the overheads of dropping in and out of JNI or fork/exec then you
> can actually get pretty good performance out of a Java application.
I meant "might be".  :]

-- robin

Re: GSoC 2008 - Mentors Wanted!

[Imran M Yousuf]

On Thu, Mar 6, 2008 at 3:13 AM, Robin Rosenberg
<robin.rosenberg@dewire.com> wrote:
> Den Wednesday 05 March 2008 08.58.15 skrev Imran M Yousuf:
>
> > I would like to suggest 2 projects that I want to work as a developer
>  > (and/or mentor):
>  >
>  > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
>  > The aim of the plugin is to integrate GIT with NetBeans using JNI so
>  > that any change in the implementation of GIT does not effect the SCM
>  > plugins way of work.
>  > Language: Java
>  > Goal: Make GIT available from IDE for NetBeans users and use GIT using
>  > Java Native Interfaces
>
>  As the current acting maintainer or egit/jgit I would not mind cooperating
>  with making it available to Netbeans, J2EE and command line interface or
>  whatever.

I am honoured and would be grateful for your support.

>
>  You can make a plugin for Netbeans today that will do the basic like walking
>  the history, finding out what to commit, commit, switch/create/reset
>  branches, decorations based on jgit and you wouldn't need to change a thing
>  in jgit. There might be things you *want* to change, but that's another story
>  and applied to the continued development for the Eclipse plugin too. Even
>  the license might be changed.

I was taking a look at the Mercurial VCS Plugin for NetBeans and I
think GIT's one will be similar. Using jGit would be great; Do you
have any plans to have a Maven version of jGit so that it could be
used from any Maven project? Another question is - Is jGit dependent
on any Eclipse API (dont even bother if the answer is no)? Can we have
a separate repo for jGit so that it is maintained independently on
eGit?

>
>  You will find support in jgit for this today. Cloning over git and ssh real
>  soon. I'm clensing the oopses from the history right now. (bless rebase -i
>  and git-gui).
>
>  There are no dependencies on Eclipse and I do not plan on introducing any.
>  Jgit and Egit live in the same repo at the moment simply because there are
>  no other users of egit so far.
>
>  There might be some operations that might be harder to do well in Java. For
>  those exec'ing might be the solution, I'm thinking repack, but then I haven't
>  tried it yet. In general jgit is almost as fast as git and probably
>  outperforms git on windows as git there doesn't use  memory mapped I/O for
>  packs (something I'd expect someone or even me to fix soon). For JNI'ed
>  operations the complexity is just horrible and even when possible, there is
>  a lot of overhead for JNI itselt, conversion from UTF-16 to somehing
>  eightbitish and back. On windows there's even yet another layer of
>  eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
>  mapped I/O on all platforms that support it for pack reading.
>
>  If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
>  opinions differently.
>
>  -- robin
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557

Re: GSoC 2008 - Mentors Wanted!

[Robin Rosenberg]

Den Thursday 06 March 2008 06.33.26 skrev Imran M Yousuf:
> I am honoured and would be grateful for your support.
Great!.

> >  You can make a plugin for Netbeans today that will do the basic like
> > walking the history, finding out what to commit, commit,
> > switch/create/reset branches, decorations based on jgit and you wouldn't
> > need to change a thing in jgit. There might be things you *want* to
> > change, but that's another story and applied to the continued development
> > for the Eclipse plugin too. Even the license might be changed.
>
> I was taking a look at the Mercurial VCS Plugin for NetBeans and I
> think GIT's one will be similar. Using jGit would be great; Do you
> have any plans to have a Maven version of jGit so that it could be
> used from any Maven project? Another question is - Is jGit dependent
Same thing as with Netbeans. We don't need a special version of jgit
for Maven, Ant, Cruisecontrol, whatever. We might (will) discover new use
cases where we want to put more code into jgit because it not application
specific. So go ahead, invoke jgit, send patches etc.

-- robin

Re: GSoC 2008 - Mentors Wanted!

[Christian Couder]

Le mardi 4 mars 2008, Shawn O. Pearce a écrit :
> OK, enough, onto the project list!
>
>   http://git.or.cz/gitwiki/SoC2008Ideas
>
> That is only a starting list of possible projects.  At present Dscho
> and myself are listed as possible mentors for a vast majority of
> these projects.  I'd love to get some more members of the community
> involved this year.

I can be a co-mentor if needed, though there are currently no project on the 
wiki about parts of the code I know quite well (bisect, help, config, refs, 
GIT_TRACE). If someone has ideas in these areas that would be great.

I also can't be involved in projects on Windows or MacOS, as I use only 
Linux at home. But otherwise I am willing to co-mentor any other project.

Thanks,
Christian.

Re: GSoC 2008 - Mentors Wanted!

[Christian Couder]

Le jeudi 6 mars 2008, Christian Couder a écrit :
> Le mardi 4 mars 2008, Shawn O. Pearce a écrit :
> > OK, enough, onto the project list!
> >
> >   http://git.or.cz/gitwiki/SoC2008Ideas
> >
> > That is only a starting list of possible projects.  At present Dscho
> > and myself are listed as possible mentors for a vast majority of
> > these projects.  I'd love to get some more members of the community
> > involved this year.
>
> I can be a co-mentor if needed, though there are currently no project on
> the wiki about parts of the code I know quite well (bisect, help, config,
> refs, GIT_TRACE). If someone has ideas in these areas that would be
> great.

By the way, perhaps we could send some "Call for Git GSoC ideas" messages on 
the kernel mailing list and other mailing lists of projects using Git, to 
ask them to send us on git@vger.kernel.org some ideas.

Regards,
Christian.

Re: GSoC 2008 - Mentors Wanted!

[Shawn O. Pearce]

Christian Couder <chriscool@tuxfamily.org> wrote:
> Le jeudi 6 mars 2008, Christian Couder a écrit :
> > Le mardi 4 mars 2008, Shawn O. Pearce a écrit :
> > > OK, enough, onto the project list!
> > >
> > >   http://git.or.cz/gitwiki/SoC2008Ideas
> > >
> > > That is only a starting list of possible projects.  At present Dscho
> > > and myself are listed as possible mentors for a vast majority of
> > > these projects.  I'd love to get some more members of the community
> > > involved this year.
> >
> > I can be a co-mentor if needed, though there are currently no project on
> > the wiki about parts of the code I know quite well (bisect, help, config,
> > refs, GIT_TRACE). If someone has ideas in these areas that would be
> > great.
> 
> By the way, perhaps we could send some "Call for Git GSoC ideas" messages on 
> the kernel mailing list and other mailing lists of projects using Git, to 
> ask them to send us on git@vger.kernel.org some ideas.

That's a pretty good idea.

Unfortunately I don't run in those circles.  But I guess I can throw
a message at a few of our user mailing lists as our GSoC org admin
and see if they have anything.

-- 
Shawn.