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@xxxxxxxxx> wrote: > On Thu, Apr 26, 2012 at 12:15 AM, Subho Banerjee <subs.zero@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html