Michael G Schwern <schw...@pobox.com> 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.


> >> +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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to