git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Git.pm

From
Subho Banerjee <subs.zero@gmail.com>
Date
Apr 26, 2012, 04:15 UTC
Message-ID
<CAB3zAY3-Bn86bCr7Rxqi4vxbYFxUesLwm8gddxyMSexov2tOhw@mail.gmail.com>

Hello, I had made a proposal for the Git.pm project in GSoC. The proposal did not get accepted, however, I see that no one in the GSoC accepted list is actually working on the Git.pm project. If some of you could give me some of your time in terms of advice on what exactly is needed for the module, I am willing to work over the summer to get this module production-ready. I can probably put in 15-20 hours a week on this project from May to August. I believe that will be enough time to roughly complete all that I had enumerated in my GSoC proposal. This of course will be strictly outside the GSoC framework.

I plan to start coding on the project by 7th May and use the time from then to now to investigate what code is there/ what is to be done etc. I had made an approximate timeline for the GSoC proposal and I would like to follow it - ---> [By 15th May] Get the current perl code, to use another mechanism of throwing errors(Try:Tiny) ---> [By August] Get in place a more robust perl wrapper ie. expand the code have a couple of more objects, Git::Repo, Git::Config etc. ---> If all goes well, then by the beginning of August, get the perl module ready for CPANfication

I also had a couple of questions - ---> Do I base my code revisions on the master branch of the Git codebase[https://github.com/git/git]? Or is there some other repository which might be more recent. ---> I saw gitweb-caching code from a previous GSoC project, the perl module there seems to have been developed beyond what is there in the master brach? However, these changes are atleast a couple of years old and havent been incorporated in the main codebase... Is there any particular reason for that? ---> I see in the code that it says that the API is experimental. Is there any absolute need for backward compatibility, or can I try to redesign the API somewhat extensively?

Also, any suggestions and tips you can give me about the project will be very helpful.

Cheers, Subho.

Next: Randal L. Schwartz
Message 1 of 24 in “Git.pm”
  1. Subho BanerjeeApr 26, 2012
  2. Randal L. SchwartzApr 26, 2012
  3. Tim HeniganApr 26, 2012
  4. Subho BanerjeeApr 26, 2012
  5. Jonathan NiederApr 26, 2012
  6. Subho BanerjeeMay 10, 2012
  7. Jonathan NiederMay 10, 2012
  8. demerphqMay 10, 2012
  9. Subho BanerjeeMay 10, 2012
  10. demerphqMay 10, 2012
  11. Junio C HamanoMay 10, 2012
  12. demerphqMay 10, 2012
  13. Andrew SayersMay 10, 2012
  14. demerphqMay 11, 2012
  15. Randal L. SchwartzMay 11, 2012
  16. Junio C HamanoMay 11, 2012
  17. [GIT.PM 1/3] Ignore files produced from exuberant-ctagsSubho Sankar Banerjee, May 19, 2012
  18. [GIT.PM 2/3] Getting rid of throwing Error::Simple objects in favour of simple Perl scalars which can be caught in eval{} blocksSubho Sankar Banerjee, May 19, 2012
  19. Andrew SayersMay 19, 2012
  20. Subho BanerjeeMay 23, 2012
  21. Andrew SayersMay 23, 2012
  22. [GIT.PM 3/3] Perl code uses eval{}/die instead of Error::Simple and Git::Error::CommandSubho Sankar Banerjee, May 19, 2012
  23. Junio C HamanoApr 26, 2012
  24. Sam VilainApr 26, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.