app::kgb::client::git(3pm) [debian man page]

App::KGB::Client::Git(3pm)				User Contributed Perl Documentation				App::KGB::Client::Git(3pm)

NAME

       App::KGB::Client::Git - Git supprot for KGB client

SYNOPSYS

       my $c = App::KGB::Client::Git->new({
	   ...
	   git_dir => '/some/where',   # defaults to $ENV{GIT_DIR}
	   old_rev     => 'a7c42f58',
	   new_rev     => '8b37ed8a', });

DESCRIPTION

       App::KGB::Client::Git provides KGB client with knowledge about Git repositories. Its  method returns a series of App::KGB::Commit objects,
       each corresponding to the next commit of the received series.

CONSTRUCTION

   App::KGB::Client::Git->new( { parameters... } )
       Input data can be given in any of the following ways:

       as parameters to the constructor
	       # a single commit
	       my $c = App::KGB::Client::Git->new({
		   old_rev => '9ae45bc',
		   new_rev => 'a04d3ef',
		   refname => 'master',
	       });

       as a list of revisions/refnames
	       # several commits
	       my $c = App::KGB::Client::Git->new({
		   changesets  => [
		       [ '4b3d756', '62a7c8f', 'master' ],
		       [ '7a2fedc', '0d68c3a', 'my'	],
		       ...
		   ],
	       });

	   All the other ways to supply the changes data is converted internally to this one.

       in a file whose name is in the reflog parameter
	   A file name of "-" means standard input, which is the normal way for Git post-receive hooks to get the data.

	   The file must contain three words separated by spaces on each line. The first one is taken to be the old revision, the second is the
	   new revision and the third is the refname.

       on the command line
	   Useful when testing the KGB client from the command line. If neither old_rev, new_rev, refname nor changesets is given to the
	   constructor, and if @ARGV has exactly three elements, they are taken to be old revision, new revision and refname respectively. Only
	   one commit can be represented on the command line.

       In all of the above methods, the location of the .git directory can be given in the git_dir parameter, or it will be taken from the
       environment variable GIT_DIR.

METHODS

       describe_commit
	   Returns an instance of App::KGB::Change class for each commit. Returns undef when all commits were processed.

COPYRIGHT &; LICENSE
       Copyright (c) 2009 Damyan Ivanov

       Based on the shell post-recieve hook by Andy Parkins

       This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the
       Free Software Foundation; either version 2 of the License, or (at your option) any later version.

       This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

       You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation,
       Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

perl v5.12.4							    2011-09-15						App::KGB::Client::Git(3pm)

Check Out this Related Man Page

App::Cmd::Setup(3pm)					User Contributed Perl Documentation				      App::Cmd::Setup(3pm)

NAME

       App::Cmd::Setup - helper for setting up App::Cmd classes

VERSION

       version 0.318

OVERVIEW

       App::Cmd::Setup is a helper library, used to set up base classes that will be used as part of an App::Cmd program.  For the most part you
       should refer to the tutorial for how you should use this library.

       This class is useful in three scenarios:

       when writing your App::Cmd subclass
	   Instead of writing:

	     package MyApp;
	     use base 'App::Cmd';

	   ...you can write:

	     package MyApp;
	     use App::Cmd::Setup -app;

	   The benefits of doing this are mostly minor, and relate to sanity-checking your class.  The significant benefit is that this form
	   allows you to specify plugins, as in:

	     package MyApp;
	     use App::Cmd::Setup -app => { plugins => [ 'Prompt' ] };

	   Plugins are described in App::Cmd::Tutorial and App::Cmd::Plugin.

       when writing abstract base classes for commands
	   That is: when you write a subclass of App::Cmd::Command that is intended for other commands to use as their base class, you should use
	   App::Cmd::Setup.  For example, if you want all the commands in MyApp to inherit from MyApp::Command, you may want to write that package
	   like this:

	     package MyApp::Command;
	     use App::Cmd::Setup -command;

	   Do not confuse this with the way you will write specific commands:

	     package MyApp::Command::mycmd;
	     use MyApp -command;

	   Again, this form mostly performs some validation and setup behind the scenes for you.  You can use "base" if you prefer.

       when writing App::Cmd plugins
	   App::Cmd::Plugin is a mechanism that allows an App::Cmd class to inject code into all its command classes, providing them with utility
	   routines.

	   To write a plugin, you must use App::Cmd::Setup.  As seen above, you must also use App::Cmd::Setup to set up your App::Cmd subclass if
	   you wish to consume plugins.

	   For more information on writing plugins, see App::Cmd::Manual and App::Cmd::Plugin.

AUTHOR

       Ricardo Signes <rjbs@cpan.org>

COPYRIGHT AND LICENSE

       This software is copyright (c) 2012 by Ricardo Signes.

       This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

perl v5.14.2							    2012-05-05						      App::Cmd::Setup(3pm)

Linux and UNIX Man Pages

app::kgb::client::git(3pm) [debian man page]

Check Out this Related Man Page