Re: [PATCH 1/4] Extract some utilities from git-svn to allow extracting Git::SVN.

[Michael G Schwern <schwern@pobox.com>]

This is rapidly getting into the weeds.  Regardless of the debate below, what
would you like me to do?  Switch indentation to tabs and resubmit?  AFAIK only
the new tests are affected.


On 2012.7.25 4:08 PM, Eric Wong wrote:
>>>> +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.

Perhaps this is self fulfilling.  Would you like to attract more Perl programmers?


> 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.

Storage costs a dime a gig.  One extra music file negates your space savings.
 I have more CPU power on my phone than I had on my desktop "many years ago".
 It doesn't matter if tabs make git-grep 20% faster because it's going to be
200ms vs 240ms.

Regardless, you don't choose your coding style because it's easier for the
computer.  You choose it because it makes the code easier for humans to work with.


> (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.

What you say above is correct, but the extra space is not wasted.  It would be
like complaining about all the space that Documentation takes up, and that it
shows preference towards English.  Its *useful* to somebody not already using
your style.  It's useful for new-to-your-project folks.  It's also useful for
somebody switching between the C and Perl code (though a good editor should
already be set up to do C and Perl differently).

Are the editor wars still going on here?  Is somebody going to be *offended*
if their editor isn't represented?  If so, shouldn't they grow up?


>> 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.

I agree that mixing the style within the Perl code isn't good.  Perl code can
very quickly be reformatted.  A basic perltidy config can help keep it that way.


-- 
Alligator sandwich, and make it snappy!