From: Tim Henigan <tim.henigan@gmail.com>
To: Subho Banerjee <subs.zero@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Git.pm
Date: Thu, 26 Apr 2012 14:58:37 -0400 [thread overview]
Message-ID: <CAFouetgwRpB1GFJOC8PTVryVY-94S3xa5ZiSaWQWoz070qQ-6g@mail.gmail.com> (raw)
In-Reply-To: <CAB3zAY3-Bn86bCr7Rxqi4vxbYFxUesLwm8gddxyMSexov2tOhw@mail.gmail.com>
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.
next prev parent reply other threads:[~2012-04-26 18:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-26 4:15 Git.pm Subho Banerjee
2012-04-26 18:41 ` Git.pm Randal L. Schwartz
2012-04-26 18:58 ` Tim Henigan [this message]
2012-04-26 20:10 ` Git.pm Subho Banerjee
2012-04-26 20:31 ` Git.pm Jonathan Nieder
2012-05-10 13:19 ` Git.pm Subho Banerjee
2012-05-10 15:16 ` Git.pm Jonathan Nieder
2012-05-10 15:54 ` Git.pm demerphq
2012-05-10 16:18 ` Git.pm Subho Banerjee
2012-05-10 17:22 ` Git.pm demerphq
2012-05-10 16:20 ` Git.pm Junio C Hamano
2012-05-10 17:38 ` Git.pm demerphq
2012-05-10 20:55 ` Git.pm Andrew Sayers
2012-05-11 8:27 ` Git.pm demerphq
2012-05-11 16:56 ` Git.pm Randal L. Schwartz
2012-05-11 18:10 ` Git.pm Junio C Hamano
2012-05-19 7:08 ` [PATCH][GIT.PM 1/3] Ignore files produced from exuberant-ctags Subho Sankar Banerjee
2012-05-19 7:08 ` [PATCH][GIT.PM 2/3] Getting rid of throwing Error::Simple objects in favour of simple Perl scalars which can be caught in eval{} blocks Subho Sankar Banerjee
2012-05-19 9:38 ` Andrew Sayers
2012-05-23 11:02 ` Subho Banerjee
2012-05-23 19:36 ` Andrew Sayers
2012-05-19 7:08 ` [PATCH][GIT.PM 3/3] Perl code uses eval{}/die instead of Error::Simple and Git::Error::Command Subho Sankar Banerjee
2012-04-26 19:17 ` Git.pm Junio C Hamano
2012-04-26 19:59 ` Git.pm Sam Vilain
-- strict thread matches above, loose matches on Subject: below --
2008-11-19 17:56 Git.pm nadim khemir
2008-11-20 8:34 ` Git.pm Petr Baudis
2008-11-20 13:07 ` Git.pm Petr Baudis
2008-11-23 19:58 ` Git.pm nadim khemir
2008-12-07 17:39 ` Git.pm nadim khemir
2008-11-21 2:56 ` Git.pm Jakub Narebski
2008-11-23 20:09 ` Git.pm nadim khemir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFouetgwRpB1GFJOC8PTVryVY-94S3xa5ZiSaWQWoz070qQ-6g@mail.gmail.com \
--to=tim.henigan@gmail.com \
--cc=git@vger.kernel.org \
--cc=subs.zero@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.