From: Subho Banerjee Date: Thu, 26 Apr 2012 20:10:07 GMT Subject: Re: Git.pm Message-ID: In-Reply-To: Hello, I will take care that I dont break those. 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? 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? Cheers, Subho. On Fri, Apr 27, 2012 at 12:28 AM, Tim Henigan wrote: > On Thu, Apr 26, 2012 at 12:15 AM, Subho Banerjee wrote: >> >> ---> 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? > > A quick grep of the code in 'master' shows Git.pm used in the following: > >    - contrib/examples/git-remote.perl >    - git-add--interactive.perl >    - git-cvsexportcommit.perl >    - git-send-email.perl >    - git-svn.perl >    - t/perf/aggregate.perl > > There is also work in progress on 'pu' that relies on Git.pm. > > Breaking any of these scripts would be bad.  You may be able to > refactor them at the same time Git.pm is modified, but it would be > wise to contact the authors before making any major changes.