GSoC questions

GSoC questions

[Alexandru Sutii]

Hello!

My name is Alexandru Sutii and I would like to participate as a student at GSoc.
I am interested in two projects from your list:
- Build a minimal Git client based on libgit2
- Port Git to Android
My questions are:
- How important are these projects for the community?
- Should I provide a patch in order to prove that I am suited for one of these
projects?
  If so, what specifically should I implement?

Thank you,
Alexandru.

Re: GSoC questions

[Jonathan Nieder]

Hi,

Alexandru Sutii wrote:

> I am interested in two projects from your list:
> - Build a minimal Git client based on libgit2
> - Port Git to Android
> My questions are:
> - How important are these projects for the community?
> - Should I provide a patch in order to prove that I am suited for one of these
> projects?
>   If so, what specifically should I implement?

Thanks for writing.  The "minimal Git client" task seems like a
popular one.  Luckily that is not a fatal problem --- git has many
subcommands, so even if every proposal is about that, it could be
possible to subdivide the work and produce something interesting.

Some reading matter:

 http://thread.gmane.org/gmane.comp.version-control.git/99608/focus=99682
 http://thread.gmane.org/gmane.comp.version-control.git/169498/focus=169517
 http://thread.gmane.org/gmane.comp.version-control.git/169498/focus=169762
 http://thread.gmane.org/gmane.comp.version-control.git/170032/focus=170076

Is there some particular part of git functionality you would like to
focus on (history creation, history mining, object store maintenance,
configuration, transport)?  The list of low-level commands (plumbing)
in the git manual might be a good place to get an idea of the scope.

The ideas page mentions areas in which libgit2 functionality is
incomplete --- depending on your interest, you might want to focus on
one of these (so the project would be to add functionality to libgit2
as well as using it) or to steer clear of them (to focus on
functionality libgit2 already has).

So, to make a long story short: there is something sneaky about us
presenting this idea, since there is so much room for choice.  As your
project becomes more precise it should be possible for people on the
list to give more detailed advice.

Cc-ing the libgit2 list and Jeff King for more hints.

As for porting git to Android: that idea is less concrete to me.  A
native Android app would presumably be in Java, so most likely your
best bet is to talk to someone involved in the JGit project[1].

Another note.  Please feel free to venture beyond projects listed on
the ideas page.  For example the 2010 ideas page contains some gems:

 https://git.wiki.kernel.org/index.php/SoC2010Ideas#Several_small_projects_improving_msysGit

as does the 2008 page if you can get Nicolas Pitre on board :)

 https://git.wiki.kernel.org/index.php/SoC2008Ideas#Implement_pack_v4.2Fv5_for_higher_compression

Really, if you name any git-related topic you're interested in,
chances are we can come up together with something valuable and
interesting to work on in that area.

Lastly, as far as patches go: yes, it would be excellent (and it would
show initiative) to offer an experience of what it is like to work
with you (if you end up finding time for this).

Git may misbehave; or while getting up to speed on some aspect of its
behavior you may find some documentation confusing; or you may wonder,
"why is this code doing such a slow/unreliable/otherwise insane
thing?"  When the moment comes, look straight to
Documentation/SubmittingPatches and it will tell what to do. :)

Good luck with whatever project you decide,
Jonathan

[1] http://wiki.eclipse.org/Google_Summer_of_Code_2011_Ideas#Ideas_submission
http://eclipse.org/jgit/developers/

Re: GSoC questions

[Jeff King]

On Sun, Mar 27, 2011 at 07:11:53PM -0500, Jonathan Nieder wrote:

> The ideas page mentions areas in which libgit2 functionality is
> incomplete --- depending on your interest, you might want to focus on
> one of these (so the project would be to add functionality to libgit2
> as well as using it) or to steer clear of them (to focus on
> functionality libgit2 already has).
> 
> So, to make a long story short: there is something sneaky about us
> presenting this idea, since there is so much room for choice.  As your
> project becomes more precise it should be possible for people on the
> list to give more detailed advice.

Yes. I didn't write those ideas on the idea page, but I do like their
sneakiness. On the ideas I put up, I also tried to be a little bit
vague.

Because I'd really rather see a student not do a proposal based on one
of our ideas as a checklist of things to code. I'd much rather give them
a _problem_, then come up with and implement their own solution,
figuring out the requirements and the best way to go about it
themselves (with hints from the community, of course; none of us works
in a vacuum, and certainly somebody new to the project isn't going to
always know the best way to go about things).

But GSoC (IMHO) is not just about getting code written. It's also about
showing students what it's like to take part in open source projects,
and to see a problem in need of solving and scratch that itch. And from
the project's perspective, hopefully that gets the student addicted to
scratching itches and they keep doing it.

> Another note.  Please feel free to venture beyond projects listed on
> the ideas page.  For example the 2010 ideas page contains some gems:

I very much agree with this. Though I would caution students to talk to
the community a bit before doing a proposal for something out of the
blue. Because often people have tried and failed at something similar
before, and knowing the context helps. So post to the list and say "I am
thinking of doing X. Has anybody done something like it before? What
would be the best way to go about?"

-Peff

Re: GSoC questions

[Alexandru Sutii]

> Is there some particular part of git functionality you would like to
> focus on (history creation, history mining, object store maintenance,
> configuration, transport)?  The list of low-level commands (plumbing)
> in the git manual might be a good place to get an idea of the scope.
>
> The ideas page mentions areas in which libgit2 functionality is
> incomplete --- depending on your interest, you might want to focus on
> one of these (so the project would be to add functionality to libgit2
> as well as using it) or to steer clear of them (to focus on
> functionality libgit2 already has).

Hello again! Thanks for your and Jeff's reply.

I have decided on "minimal Git client based on libgit2" project. I have looked
over the git manual page and I would like to work on manipulation commands
functionality. I am also open for adding functionality to libgit2 as
well as using it.

I have read the references from your mail and I am currently trying to
understand project's architecture, as I am totally new to git's source code.
Hope I will manage to identify the source code parts that interest me in
a short time and maybe realize to implement something.

In the meantime I would greatly appreciate some guidelines where to look.

--Alex.

Re: GSoC questions

[Vicent Marti]

Hey Alex,

I'm glad to see you're interested on the minimal git client task.

Here are some places to get you started on writing your proposal:

http://libgit2.github.com/libgit2/index.html (the full API
documentation -- priceless)
http://libgit2.github.com/api.html (the usage guide, with examples)
https://github.com/libgit2 (the list of language bindings, so you can
see real-life usage samples)

Also, I have to agree with Jeff once again: Start researching and
impress us with an awesome application that shows how are you planning
to solve the problem you are facing -- in this case writing a minimal
git client.

Remember that the sooner your application gets on Melange, the more
feedback it will receive!

Cheers,
Vicent


On Mon, Mar 28, 2011 at 11:26 PM, Alexandru Sutii <sutii.alex@gmail.com> wrote:
>> Is there some particular part of git functionality you would like to
>> focus on (history creation, history mining, object store maintenance,
>> configuration, transport)?  The list of low-level commands (plumbing)
>> in the git manual might be a good place to get an idea of the scope.
>>
>> The ideas page mentions areas in which libgit2 functionality is
>> incomplete --- depending on your interest, you might want to focus on
>> one of these (so the project would be to add functionality to libgit2
>> as well as using it) or to steer clear of them (to focus on
>> functionality libgit2 already has).
>
> Hello again! Thanks for your and Jeff's reply.
>
> I have decided on "minimal Git client based on libgit2" project. I have looked
> over the git manual page and I would like to work on manipulation commands
> functionality. I am also open for adding functionality to libgit2 as
> well as using it.
>
> I have read the references from your mail and I am currently trying to
> understand project's architecture, as I am totally new to git's source code.
> Hope I will manage to identify the source code parts that interest me in
> a short time and maybe realize to implement something.
>
> In the meantime I would greatly appreciate some guidelines where to look.
>
> --Alex.
> --
> 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 questions

[Alexandru Sutii]

> Here are some places to get you started on writing your proposal:
>
> http://libgit2.github.com/libgit2/index.html (the full API
> documentation -- priceless)
> http://libgit2.github.com/api.html (the usage guide, with examples)
> https://github.com/libgit2 (the list of language bindings, so you can
> see real-life usage samples)

Hello again!

First of all thanks a lot for the references. You have helped me a lot.

> Also, I have to agree with Jeff once again: Start researching and
> impress us with an awesome application that shows how are you planning
> to solve the problem you are facing -- in this case writing a minimal
> git client.
>
> Remember that the sooner your application gets on Melange, the more
> feedback it will receive!

I began implementing the minimal git client[1]. I have implemented the
"git-mktag" command. For this I have modified the "mktag.c" file from
the "builtin" directory in order to make it run with libgit2. Basically the
input file verification code is the same with the original one. I have just
extracted the sha1, the object type, the tag name, the tagger, the
comment and created a tag with git_tag_create.

I have also used the original "usage.c" and "git-compat-util.h" for
error handling.
Is there a problem if the git2 client will reuse non-gitcore code, such
as string parsing code, parameter parsing code, etc?

Can someone look on my code and give me some feedback?

Just before ending the implementation of the mktag command I have
started thinking that maybe there was no need to reimplement this
command, as it can be considered that libgit2 already has this feature.
Even if it is so I am not sorry I did this, because by reimplementig it I
had the chance to get used with git code and with libgit2 API.

--Alex

[1] https://github.com/sutiialex/Git2

Re: GSoC questions

[Motiejus Jakštys]

On Thu, Mar 31, 2011 at 12:36:15PM +0300, Alexandru Sutii wrote:
> I began implementing the minimal git client[1]. I have implemented the
> "git-mktag" command. For this I have modified the "mktag.c" file from
> the "builtin" directory in order to make it run with libgit2. Basically the
> input file verification code is the same with the original one. I have just
> extracted the sha1, the object type, the tag name, the tagger, the
> comment and created a tag with git_tag_create.

Hi there,

I started git2 client a couple of days ago and implemented a rough
version of rev-list.c (which shows rev-list of HEAD. It is here:
https://github.com/Motiejus/git2/

Vincent van Ravesteijn forked and made some modifications:
https://github.com/vfr-nl/git2/
Thanks to him for CMakeLists.txt.

> 
> I have also used the original "usage.c" and "git-compat-util.h" for
> error handling.  Is there a problem if the git2 client will reuse
> non-gitcore code, such as string parsing code, parameter parsing code,
> etc?

I think this is what it has to be like. Provided it adds no
requirements and license issues.

> 
> Can someone look on my code and give me some feedback?

You have done a good job in creating handlers and hooking up the
repository. Thank you.

> 
> Just before ending the implementation of the mktag command I have
> started thinking that maybe there was no need to reimplement this
> command, as it can be considered that libgit2 already has this
> feature.  Even if it is so I am not sorry I did this, because by
> reimplementig it I had the chance to get used with git code and with
> libgit2 API.

Don't know about the actual tag implementation, but in any case, the
wrapper (glue) code around the tag very helpful.

Best,
Motiejus

Re: GSoC questions

[Vincent van Ravesteijn]

On Thu, Mar 31, 2011 at 11:36 AM, Alexandru Sutii <sutii.alex@gmail.com> wrote:
> I have also used the original "usage.c" and "git-compat-util.h" for
> error handling.
> Is there a problem if the git2 client will reuse non-gitcore code, such
> as string parsing code, parameter parsing code, etc?

I guess the git2 client will consist solely of non-gitcore code, as
all the gitcore code will be part of libgit2 eventually.

I expect the transition to be not so difficult for many commands, but
the challenge I see is to do it not by 'reusing' git code, but by
'sharing' the code. Otherwise we end up with a second Git and someone
should spend a lifetime to keep the reused code in synchronisation
with the git repo.

This might, however, require some (major) refactorization to the Git
code. I don't know whether that will be supported by everyone.

On the other hand, we will get the bonus that using libgit2 in the
upstream git code is then becoming more trivial.

Maybe I'm aiming at too much here. It could well be that it is worth
writing the minimal git client to just be able to test libgit2 using
the git tests. Does anyone want to comment ?

Vincent

Re: GSoC questions

[Alexandru Sutii]

> I guess the git2 client will consist solely of non-gitcore code, as
> all the gitcore code will be part of libgit2 eventually.
>
> I expect the transition to be not so difficult for many commands, but
> the challenge I see is to do it not by 'reusing' git code, but by
> 'sharing' the code. Otherwise we end up with a second Git and someone
> should spend a lifetime to keep the reused code in synchronisation
> with the git repo.
>
> This might, however, require some (major) refactorization to the Git
> code. I don't know whether that will be supported by everyone.
>
> On the other hand, we will get the bonus that using libgit2 in the
> upstream git code is then becoming more trivial.
>
> Maybe I'm aiming at too much here. It could well be that it is worth
> writing the minimal git client to just be able to test libgit2 using
> the git tests. Does anyone want to comment ?

Hello!

There have been a lot on discussions on the mailing list regarding
on what this client should look like and I understand that we are
expected to come with a specific approach. Also I understand there is
no interest for this project to become large.

Considering this circumstances I think we should implement the client
with the basic commands by reusing git's high level code. I am for building
it independently of the git's mainstream.

Anyway I am open to any proposals. Comments are still welcome.

--Alex

Re: GSoC questions

[Jeff King]

On Thu, Mar 31, 2011 at 01:58:23PM +0200, Vincent van Ravesteijn wrote:

> On Thu, Mar 31, 2011 at 11:36 AM, Alexandru Sutii <sutii.alex@gmail.com> wrote:
> > I have also used the original "usage.c" and "git-compat-util.h" for
> > error handling.
> > Is there a problem if the git2 client will reuse non-gitcore code, such
> > as string parsing code, parameter parsing code, etc?
> 
> I guess the git2 client will consist solely of non-gitcore code, as
> all the gitcore code will be part of libgit2 eventually.
> 
> I expect the transition to be not so difficult for many commands, but
> the challenge I see is to do it not by 'reusing' git code, but by
> 'sharing' the code. Otherwise we end up with a second Git and someone
> should spend a lifetime to keep the reused code in synchronisation
> with the git repo.
> 
> This might, however, require some (major) refactorization to the Git
> code. I don't know whether that will be supported by everyone.

I had sort of assumed that git-core code would be taken as inspiration,
but that it would be an entirely new implementation, based around the
error handling and build infrastructure provided by libgit2.

And obviously libgit2 isn't going to provide everything you need. For
example, in the mktag implementation that Alex posted, there's still a
big verify_and_create_tag() function. I would prefer to see that code
broken into library-sized chunks and added to libgit2 itself, with the
eventual goal that mktag.c could consist of a very short main() function
that just parses options calls into the library (and yeah, I realize
that things are not always so simple, but it is a goal to work towards).

So when starting with a command, rather than trying to port code from
git.git, look at what it does and say "how would I do this in libgit2?
What else needs to be implemented in the library before I can do it?".
And then write the bulk of your code for libgit2, filling in those gaps
in functionality, and as a final step make the actual executable
command.

In this case, one of the things that is lacking is the die() error
handling. In general, that is not something libgit2 wants, because its
goal is to pass errors back up the call chain. Another thing that is
missing is option-parsing (though mktag doesn't need it). Again, not
something that libgit2 wants to use.

But maybe those are things that libgit2 should be providing to callers.
Or maybe they should be spun off into their own separate utility
library. But in either case, they should probably be pulled out of core
git, cleaned up to make them fit for library use, and then made part of
libgit2.

-Peff

Re: GSoC questions

[Jeff King]

On Thu, Mar 31, 2011 at 09:34:15PM +0300, Alexandru Sutii wrote:

> > Maybe I'm aiming at too much here. It could well be that it is worth
> > writing the minimal git client to just be able to test libgit2 using
> > the git tests. Does anyone want to comment ?
> 
> Hello!
> 
> There have been a lot on discussions on the mailing list regarding
> on what this client should look like and I understand that we are
> expected to come with a specific approach. Also I understand there is
> no interest for this project to become large.

It's OK if the project is large; it's inherently a big thing. But it's
important to bite off a small enough, useful chunk of it and work on
that. One, because you want something small enough to finish in the GSoC
time-frame. But two, because a small, solid start on a larger project is
much more useful to the community as a whole than a larger chunk that is
not-so-solid. Because people in the community (and you, if you want to
keep working on it!) may pick up the project from its state at the end
of the summer.

> Considering this circumstances I think we should implement the client
> with the basic commands by reusing git's high level code. I am for building
> it independently of the git's mainstream.

Yeah, I had always assumed it would build independent of git's
mainstream.

-Peff

Re: GSoC questions

[Vincent van Ravesteijn]

>> I guess the git2 client will consist solely of non-gitcore code, as
>> all the gitcore code will be part of libgit2 eventually.
>>
> I had sort of assumed that git-core code would be taken as inspiration,
> but that it would be an entirely new implementation, based around the
> error handling and build infrastructure provided by libgit2.

Looking at the above, I think we completely agree. When I wrote that the 
gitcore code will get into libgit2, I indeed meant that it should be 
rewritten in the libgit2 style and then be added to libgit2.

There was also temporarily the idea for GSoC to let Git use the 
libgit2-library, or maybe to libify git on the road. That's why I 
thought it might be useful if we were not going to rewrite the boring 
administration code.

Thanks for thinking along,

Vincent