Re: [PATCH 1/4] Extract some utilities from git-svn to allow extracting Git::SVN.
- From
- Eric Wong <normalperson@yhbt.net>
- Date
- Jul 25, 2012, 23:08 UTC
- Message-ID
- <20120725230833.GA23993@dcvr.yhbt.net>
- In-Reply-To
- <501075B2.8090205@pobox.com>
Michael G Schwern <schwern@pobox.com> wrote:
Show 9 quoted lines
> 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.
Show 17 quoted lines
> >> +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.