Michael G Schwern <[email protected]> wrote:
> On 2012.7.25 2:24 PM, Eric Wong wrote:
> > 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.
OK.
> >> +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.
git-svn should be all tabs (though some spaces accidentally slipped in
over the years). git maintainers are mostly C programmers used to tabs,
so non-C code should favor their expectations.
I also favor tabs since they're more space-efficient and leads to faster
"git grep" on large source trees (more important for bigger projects).
I remember many years ago "git grep" was shown to be ~20% faster on
a source tree with tabs.
(I'm neither a kernel hacker nor a regular Perl hacker)
> 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.
I don't like them, and I think others here frowns upon them, too. They
take too much space and shows favor/preference towards certain editors.
It'll be a bigger problem if more editors become popular and we start
"supporting" them.
> The important thing is to have one less special thing a new-to-your-project
> Perl programmer has to do.
Historically git development has catered to C programmers used to tabs.
I think the mixing of indentation styles in current Perl files is the
most confusing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
