Michael G Schwern <schwern@xxxxxxxxx> wrote:
> 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.
Yes, unless Jonathan (or anybody else) has more comments.
> 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 prefer programmers not tied to a particular language.
> > 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.
It's also kernel page cache overhead.
> 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.
Hard tabs also happen to be the default indent for my editor (which
is also a popular editor) and slightly easier for me.
> >> 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?
It's not about editor wars, but unnecessary code churn to accept/review
patches to support new editors, making it a maintenance burden. Picking
up (and following) existing conventions within a project ought to be
common sense.
Anyways I don't speak for others, but seeing how we've gone all these
years without editor-specific comments, I don't believe other git devs
want them, either.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html