Re: Git.pm
- From
Subho Banerjee <subs.zero@gmail.com>
- Date
- Apr 26, 2012, 20:10 UTC
- Message-ID
- <CAB3zAY0NeXuH-wXyYkbim5U74eANY4hq5D6SsVLu3KeUqHFqzQ@mail.gmail.com>
- In-Reply-To
- <CAFouetgwRpB1GFJOC8PTVryVY-94S3xa5ZiSaWQWoz070qQ-6g@mail.gmail.com>
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 <tim.henigan@gmail.com> wrote:
Show 20 quoted lines
> On Thu, Apr 26, 2012 at 12:15 AM, Subho Banerjee <subs.zero@gmail.com> 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.