On 2012.7.25 2:24 PM, Eric Wong wrote:
> Please keep Jonathan Cc:-ed, he's been very helpful with this series
> (and very helpful in general :)

I will try.

>> +use Test::More 'no_plan';
> Didn't we agree to use done_testing()?   Perhaps (as you suggested) with
> a private copy of Test::More?  It's probably easier to start using
> done_testing() earlier rather than later.

Yes, we agreed done_testing is the way forward.  Given how much work I've had
to do to get even basic patches in I decided to ditch anything extra.  That
includes adding a t/lib and I didn't want to make it silently depend on an
upgraded Test::More either.

There's not much difference if we do it later.  Switching to done_testing is
trivial.  I'd like to get the big class extractions in so code stops shifting
around, and worry about the minutia of test plans later.  If it happens before
I get to it, great!

PS  Those t/Git-SVN/ tests are not tied into the normal testing process.  I
felt writing the tests now was important and they could be integrated into the
test suite later.

>> +BEGIN {
>> +    # Override exit at BEGIN time before Git::SVN::Utils is loaded
>> +    # so it will see our local exit later.
>> +    *CORE::GLOBAL::exit = sub(;$) {
>> +        return @_ ? CORE::exit($_[0]) : CORE::exit();
>> +    };
>> +}
> For new code related to git-svn, please match the existing indentation
> style (tabs) prevalent in git-svn.  Most of the Perl found in git also
> uses tabs for indentation.

About that.  I followed kernel style in existing code, but felt that new code
would do better to follow Perl style.  The existing Perl code mixes tabs and
spaces, so I felt it wasn't a strongly held style.  You'll get more Perl
programmers to work on the Perl code by following Perl style in the Perl code
rather than kernel style.

Alternatively, how about allowing emacs/vim configuration comments?  The
Kernel coding style doesn't allow them, how do you folks feel?  Then people
don't have to guess the style and reconfigure their editor, their editor will
do it for them.

The important thing is to have one less special thing a new-to-your-project
Perl programmer has to do.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to