Hi, I'm a computer engineering student and I'm considering libgit2 as a possible choice for application. I've read the git ideas for the current and past editions of gsoc, and I think I could do something with libgit2. Is there any formal requirements? I'm aware of the git coding standards, have moderate skills on C programming, and some reasonable background with git. Also, I would like to discuss the proposed libgit2 features with someone, is this list the apropriated place, or somewhere else wold be better (git@vger, #git or #git-devel)? Regards, Ivan -- Ivan Sichmann Freitas GNU/Linux user #509059
Hi, Ivan Sichmann Freitas wrote: > Is there any formal requirements? I'm aware of the git coding standards, > have moderate skills on C programming, and some reasonable background with git. > Also, I would like to discuss the proposed libgit2 features with someone, is > this list the apropriated place, or somewhere else wold be better (git@vger, > #git or #git-devel)? A good way is to get started playing around with libgit asap to see if the project and you work well together. :) To answer your questions: - to the best of my knowledge, I think you're in the right place for discussing proposed libgit2 features. That said, if you'd like feedback from git@vger then please feel free to cc them! If I ran the world then git@vger would be subscribed to the libgit2 list so such cc's would happen automatically. - IRC can be a good place to get questions answered but mailing lists tend to be better for sharing your work (yes, even learning is work that tends to improve the documentation) and getting other people involved. I'm not sure if libgit2 has an IRC channel. Hope that helps, Jonathan
On Fri, Mar 18, 2011 at 05:31:38PM -0500, Jonathan Nieder wrote: > A good way is to get started playing around with libgit asap to see if > the project and you work well together. :) To answer your questions: I've built libgit2 from its repository and made a few programs with it, the api seems intuitive (given some basic knowledge of git's internals) and the doxygen documentation is very complete. I will dig a little deeper later (more complex test programs, and will try some bindings, like pygit2 and luagit2). > - to the best of my knowledge, I think you're in the right place for > discussing proposed libgit2 features. That said, if you'd like > feedback from git@vger then please feel free to cc them! If I ran > the world then git@vger would be subscribed to the libgit2 list so > such cc's would happen automatically. > > - IRC can be a good place to get questions answered but mailing lists > tend to be better for sharing your work (yes, even learning is > work that tends to improve the documentation) and getting other > people involved. I'm not sure if libgit2 has an IRC channel. Thanks for the info. I still prefer mailing lists over irc channels, but irc is sometimes very good for some quick talk. Anyway, I'll hang on #git and #git-dev (ISF, if someone wants to talk). Also, I would note that the api description and doxygen docs are showing git_person as the data structure used in git_commit* functions, but since the commit 638c2ca4281589b73f2d402bb80775242045144a git_signature is used instead. Regards, Ivan -- Ivan Sichmann Freitas GNU/Linux user #509059
Hi, Talking with Vincent and reading git and libgit2's source code, I'm defining my proposal more specifically. I would like to implement the config parsing in libgit2. It will be based in the config parsing of git, but trying to utilize anything already used in other parts of libgit2. Something Vincent pointed to me, that libgit2 must be *FAST*. Besides optmizing existing git/libgit2 code, I'm stil looking for ways to make the config parsing even faster, any pointers would be appreciated. Regards, Ivan -- Ivan Sichmann Freitas GNU/Linux user #509059
Hey, On Sun, Mar 20, 2011 at 6:43 PM, Ivan Sichmann Freitas <ivansichfreitas@gmail.com> wrote: > I would like to implement the config parsing in libgit2. It will > be based in the config parsing of git, but trying to utilize anything already > used in other parts of libgit2. > > Something Vincent pointed to me, that libgit2 must be *FAST*. Besides optmizing > existing git/libgit2 code, I'm stil looking for ways to make the config parsing > even faster, any pointers would be appreciated. I could be wrong, but it seems like that might be a bit small in scope for 3 months of work. Perhaps there are other features you would like to add on - maybe config writing/updating as well? Maybe other stuff like reflog parsing? Vicent would know better than I what the scope of this work would be, but I wouldn't want you to get one month in and finishing it. :) Scott
> I could be wrong, but it seems like that might be a bit small in scope > for 3 months of work. Fair. I will talk with Vincent (or any other dev with ideas in mind) about it, or maybe think some of my own. > Perhaps there are other features you would like > to add on - maybe config writing/updating as well? Maybe other stuff > like reflog parsing? I will give a look in these ones. I was thinking in implementing maybe diff or merge algorithms (seems that diff ones have plenty of candidates at git@vger), I will study those also. Regards, Ivan -- Ivan Sichmann Freitas GNU/Linux user #509059
Yo! Indeed, as Scott is suggesting, config file parsing is not a specially time consuming project. I'd clock it at ~20h, specially if you have already planned a design beforehand. It is also not a part of the code base which needs special attention to optimization -- we are more concerned about having a sane API and making it 100% compatible with the original Git config parser. See if you can come up with more ideas to fill up your SoC schedule. Cheers, Vicent On Mon, Mar 21, 2011 at 4:48 AM, Ivan Sichmann Freitas <ivansichfreitas@gmail.com> wrote: >> I could be wrong, but it seems like that might be a bit small in scope >> for 3 months of work. > > Fair. I will talk with Vincent (or any other dev with ideas in mind) about it, > or maybe think some of my own. > >> Perhaps there are other features you would like >> to add on - maybe config writing/updating as well? Maybe other stuff >> like reflog parsing? > > I will give a look in these ones. I was thinking in implementing maybe diff or > merge algorithms (seems that diff ones have plenty of candidates at git@vger), > I will study those also. > > Regards, > Ivan > > -- > Ivan Sichmann Freitas > GNU/Linux user #509059 >
> See if you can come up with more ideas to fill up your SoC schedule. And what about the network protocol (push, pull, fetch etc.)? I'm studying the git current implementation, seems a feature that definitely should be on libgit2, but I'm not sure of the complexity. Maybe implement some core part (like the protocol itself then fetch, for example)? Any suggestions/comments? -- Ivan Sichmann Freitas GNU/Linux user #509059
Hey, On Mon, Mar 21, 2011 at 6:33 PM, Ivan Sichmann Freitas <ivansichfreitas@gmail.com> wrote: >> See if you can come up with more ideas to fill up your SoC schedule. > > And what about the network protocol (push, pull, fetch etc.)? I'm studying the > git current implementation, seems a feature that definitely should be on > libgit2, but I'm not sure of the complexity. Maybe implement some core part > (like the protocol itself then fetch, for example)? I think the push/fetch methods would be a pretty good GSoC project - you could start with http which should be the simplest and then maybe tackle the git:// protocol and possibly ssh. The protocol itself is not hugely complicated, the packfile generation may be biggest part of that, the have/needs calculation and handling would also be a bit involved, but overall I think it's a good goal. Scott
> I think the push/fetch methods would be a pretty good GSoC project - > you could start with http which should be the simplest and then maybe > tackle the git:// protocol and possibly ssh. The protocol itself is > not hugely complicated, the packfile generation may be biggest part of > that, the have/needs calculation and handling would also be a bit > involved, but overall I think it's a good goal. Great! Now that I'm on the right way, I will look a little further in the git/libgit2 code and may post a proposal draft here by tomorow. Also, thanks for the pointers. There is something I need to discuss: I'm from Brazil, south hemisphere, so here the GSoC will be, actually, during winter, at the same time my university classes will be taking place. So, in the intial phase of the project, I may be only available for 20 to 25 hours a week (I'll try to bargain some more), until the end of june, is there a problem with that? -- Ivan Sichmann Freitas GNU/Linux user #509059
Hey Ivan, if your workload is what we believe "adequate" for the Summer of Code, and you manage to finish it properly before the deadlines, it doesn't really matter how many hours you spend every week. It all depends on how quickly you can deliver quality code. :) Cheers, Vicent On Wed, Mar 23, 2011 at 3:21 AM, Ivan Sichmann Freitas <ivansichfreitas@gmail.com> wrote: >> I think the push/fetch methods would be a pretty good GSoC project - >> you could start with http which should be the simplest and then maybe >> tackle the git:// protocol and possibly ssh. The protocol itself is >> not hugely complicated, the packfile generation may be biggest part of >> that, the have/needs calculation and handling would also be a bit >> involved, but overall I think it's a good goal. > > Great! Now that I'm on the right way, I will look a little further in the > git/libgit2 code and may post a proposal draft here by tomorow. Also, thanks > for the pointers. > > There is something I need to discuss: I'm from Brazil, south hemisphere, so > here the GSoC will be, actually, during winter, at the same time my university > classes will be taking place. So, in the intial phase of the project, I may be > only available for 20 to 25 hours a week (I'll try to bargain some more), until > the end of june, is there a problem with that? > > -- > Ivan Sichmann Freitas > GNU/Linux user #509059 >
On Wed, Mar 23, 2011 at 03:51:42PM +0200, Vicent Marti wrote: > Hey Ivan, > > if your workload is what we believe "adequate" for the Summer of Code, > and you manage to finish it properly before the deadlines, it doesn't > really matter how many hours you spend every week. > > It all depends on how quickly you can deliver quality code. :) Ok, I will do my best. So here is my proposal draft. It's based on the git template, feel free to comment at will. I'm thinking in adding something (maybe the clone operation and/or git protocol). Also, I'm not completely sure on what parts I will need to call. === Proposal === Project Goals ------------- * Goal Implement the git network protocol on libgit2, via http, specifically the push and fetch operations. * Measuring success or failure Since the goal is implementing the network protocol, I would consider a succesful project if the library can push and fetch from repositories available through http protocol. * Measuring success or failure (mentor's point of view) Same as the previous topic, but making it as fast as possible. Interface (adapted for libgit, e.g., s/git/libgit2/) --------- * What parts of libgit2 will you need to call? The git object, repository and hashing parts at least. * What parts of libgit2 will you need to change? The interfacing with bindings (for providing bindings with acces to the new functions) and the building scripts (waf/cmake). I will be adding files, to interface with curl and packing the repos. About you --------- * Past projects Mostly college assignments, small patches to some vim scripts [1], [2], and packaging for Archlinux. Worked on gentoo-based brazilian linux distribution [3]. Almost everythin was codec on C, with some python and shell script experience. I'm also familiar with svn, git, doxygen. * Git experience I've started to use git 2 years ago, while learning version control systems to use on college assignments. I'm not a master at ningitsu, but know how to use most of its tools (I stil get lost on some rebases, thought). [1] http://www.vim.org/scripts/script.php?script_id=3064 [2] http://www.vim.org/scripts/script.php?script_id=1723 [3] http://librixdev.las.ic.unicamp.br/drupal/ (Portuguese) -- Ivan Sichmann Freitas GNU/Linux user #509059
Hi again. It seems my previous proposal draft was somewhat small and incomplete, so I created another one, which will probably be very similar with the one I'm submitting tomorrow. Any feedback will be very much appreciated. Also, sorry if I'm being inconvenient with this triple post. Abstract ======== The aim of libgit2 is creating a linkable, re-entrant an fast git library, enabling programs to use git resources directly. My application is to implement a very important feature, the ability to communicate with other repositories remotely, by implementing the infrastructure to use the git's network protocols. Goals ===== One feature that is still missing is the possibility of pushing, pulling, e.g., anything directly related to the network protocol. My goal will be the implementation of the network protocol in libgit2, including the infrastructure needed and the http protocol support. Specifically, the push and fetch git commands will be implemented. The main work will be creating the basic infrastructure to communicate via network protocols like http, git, and ssh. The http protocol support will also be implemented, serving to measure the success of my application. Also, special attention will be given to the new features's running speed. Planned timeline: ---------------- * In the first month, I will study the extra libraries needed (I'm almost certain of curl), some git internals, specially the object handling, and the structure of the transaction itself. Also, I will avail what parts of the current libgit2 implementation I could reuse. * In the next 1 to 3 weeks, I'll implement the transaction api, based on http protocol, trying to make it modular enough to add new protocols (git, ssh). * For 3 to 4 weeks, the git specific parts will be implemented, e.g., packfile, object handling, etc. * In the next 3 weeks, the api to the implemented features will be added, enabling bindings to use it. * The rest of the time will be spend refining the code, making it faster, more readable and such. Interface to libgit2 ==================== In libgit2 itself, few thing may be changed, most will be added. Intial planning foresee the addition of curl as a dependency, which is used because of its reliability, features and liberal license (MIT). Most of the work will be based on the original git code, trying to make it faster and re-entrant. Background ========== I'm a computer engineering student at the State University of Campinas (UNICAMP), Brazil. Most of my experience are in C programming, python and bash scripting. I have some reasonable knowledge of git, used in several contexts, from diverse college assignments to Gentoo's overlay maintenance on a local linux distribuition [1]. My work will be public available to the community through my github acount (I've already forked libgit2's repository on it). Some more important and complete work may be submitted as patches in the mailing list. Since I'm from the southern hemisphere, I don't have a full summer break to work on the project, I may be available only 15 ~ 20 hours a week in the first 2 months. By the end of june, july and beginning of august, I'll work full-time, since it is the winter break here. I sure that wouldn't be a problem, since many UNICAMP students do that and are succesful in gsoc projects (UNICAMP is well know for its gsoc participation). [1] http://librixdev.las.ic.unicamp.br/drupal/ (Portuguese) -- Ivan Sichmann Freitas GNU/Linux user #509059
Hey Ivan, this is starting to look good. Let's see what do the other mentors think about it on Melange, shall we? Cheers, Vicent On Mon, Mar 28, 2011 at 12:02 AM, Ivan Sichmann Freitas <ivansichfreitas@gmail.com> wrote: > Hi again. It seems my previous proposal draft was somewhat small and > incomplete, so I created another one, which will probably be very similar > with the one I'm submitting tomorrow. Any feedback will be very much > appreciated. Also, sorry if I'm being inconvenient with this triple > post. > > Abstract > ======== > > The aim of libgit2 is creating a linkable, re-entrant an fast git library, enabling > programs to use git resources directly. My application is to implement a very important > feature, the ability to communicate with other repositories remotely, by implementing > the infrastructure to use the git's network protocols. > > Goals > ===== > > One feature that is still missing is the possibility of pushing, pulling, e.g., > anything directly related to the network protocol. My goal will be the > implementation of the network protocol in libgit2, including the > infrastructure needed and the http protocol support. Specifically, the > push and fetch git commands will be implemented. > > The main work will be creating the basic infrastructure to communicate via > network protocols like http, git, and ssh. The http protocol support will also > be implemented, serving to measure the success of my application. Also, special > attention will be given to the new features's running speed. > > Planned timeline: > ---------------- > > * In the first month, I will study the extra libraries needed (I'm almost certain > of curl), some git internals, specially the object handling, and the structure of > the transaction itself. Also, I will avail what parts of the current libgit2 > implementation I could reuse. > * In the next 1 to 3 weeks, I'll implement the transaction api, based on http protocol, > trying to make it modular enough to add new protocols (git, ssh). > * For 3 to 4 weeks, the git specific parts will be implemented, e.g., packfile, object handling, > etc. > * In the next 3 weeks, the api to the implemented features will be added, enabling bindings > to use it. > * The rest of the time will be spend refining the code, making it faster, more readable and such. > > Interface to libgit2 > ==================== > > In libgit2 itself, few thing may be changed, most will be added. Intial planning foresee the > addition of curl as a dependency, which is used because of its reliability, features and > liberal license (MIT). > > Most of the work will be based on the original git code, trying to make it faster and re-entrant. > > Background > ========== > > I'm a computer engineering student at the State University of Campinas (UNICAMP), > Brazil. Most of my experience are in C programming, python and bash scripting. > I have some reasonable knowledge of git, used in several contexts, from diverse college > assignments to Gentoo's overlay maintenance on a local linux distribuition [1]. > > My work will be public available to the community through my github acount (I've already forked > libgit2's repository on it). Some more important and complete work may be submitted as patches > in the mailing list. > > Since I'm from the southern hemisphere, I don't have a full summer break to work on the project, > I may be available only 15 ~ 20 hours a week in the first 2 months. By the end of june, july and > beginning of august, I'll work full-time, since it is the winter break here. I sure that wouldn't > be a problem, since many UNICAMP students do that and are succesful in gsoc projects (UNICAMP is > well know for its gsoc participation). > > [1] http://librixdev.las.ic.unicamp.br/drupal/ (Portuguese) > > -- > Ivan Sichmann Freitas > GNU/Linux user #509059 >
On Mon, Mar 28, 2011 at 10:57:41PM +0300, Vicent Marti wrote: > Hey Ivan, > > this is starting to look good. Let's see what do the other mentors > think about it on Melange, shall we? Okay, already applied there. -- Ivan Sichmann Freitas GNU/Linux user #509059