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

Re: Git.pm

From
Subho Banerjee <subs.zero@gmail.com>
Date
May 10, 2012, 13:19 UTC
Message-ID
<CAB3zAY3VHtUobJfJ7=nSKb_6uJOXLGVHzR18qV6txPkzf54cDw@mail.gmail.com>
In-Reply-To
<20120426203136.GA15432@burratino>

Hello, I have started looking into how the error catching mechanism implemented right now. I have looked into the more modern error catching/throwing mechanisms in use in perl, and I am of the opinion that Try::Simple would probably be the best candidate for being the new error catching mechanism. I also wanted to discuss some aspects of the changes to be made - ------- Replacing the Error::Simple stuff should be relatively straightforward. It can be achieved with simple changes to the syntax of the perl module itself.

------- What I feel will be more complicated, and will require some discussion before it is implemented is the Git::Error module. This has modified some of the code in the original Error module and is used only when there are calls made to the git system command. Using the Try::Tiny will mean that this can be simplfied to a very large extent. As a mater of fact I am in favor of getting rid of this completely and implementing whatever is required in the Git.pm as required. Because the Try::Tiny module no longer requires exception objects to be thrown. Its just simply passing strings around.

This I believe is a big decision, and I would like to hear what you guys have to say before I actually get along changing and playing around with stuff inside the code.

Cheers, Subho.

On Fri, Apr 27, 2012 at 2:01 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 24 quoted lines
> Hi,
>
> Subho Banerjee wrote:
>
>> I will take care that I dont break those.
>
> Thanks, sounds good.
>
>>                                           Should the tests in the t/
>> folder of the codebase be enough to make sure everything is working as
>> it should be even in the Git perl module?
>
> No. :)
>
>>                                           Also is there anything like
>> a public build server which actually catalogs which tests are
>> currently failing so that I know what has gone wrong after my changes,
>> or are all commits supposed to pass every test?
>
> When tests are known to fail, they are marked with test_expect_failure
> so they don't affect the test result.
>
> Hope that helps,
> Jonathan
Previous: Jonathan NiederNext: Jonathan Nieder
Message 6 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.