Re: On Tabs and Spaces

From: Jeff King <peff@peff.net>
Date: Oct 18, 2007, 02:45 UTC
Message-ID: <20071018024553.GA5186@coredump.intra.peff.net>
In-Reply-To: <alpine.LFD.0.999.0710171753020.26902@woody.linux-foundation.org>

On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote:

> It happens. We do de-spacification in the kernel occasionally when it is 
> an annoyance. Usually it shows up in patches, though - exactly because 
> code which adds spaces instead of tabs won't line up correctly in the 
> diff.

You have made this claim several times, and I really don't understand it. If I have 8 spaces, then a diff line will have either " ", "+", or "-" followed by 8 spaces. If I use a hard tab, then the tab will end up only taking up 7 spaces because of the nature of tabs.

This might matter if I'm comparing non-diff code to diff code. But in a diff, _everything_ is indented by exactly one space, so it all lines up. Is there something I'm missing?

> So it doesn't matter *which* one you use (all spaces or all tabs) in that 
> sense.

Yes, I agree with that (even with an all-tabs policy, there are still mangled and incorrect patches that come in -- and the maintainer rejects or fixes them).

Which was what I was trying to point out with my question (though I was also curious to hear your answer): all-space versus all-tab is largely a matter of preference. And that means that people who want git to change to _their_ preference are just being silly.

Show 6 quoted lines

> And smaller *is* faster. Do something like this on the kernel:
> 
> 	GIT_PAGER= time git grep sched_fair
> 
> and then do the same thing with the kernel sources blown up by 20% by 
> de-tabification. Guess which one is 20% slower?

I was about to tell you that you're full of it, but there really is a slowdown:

$ cd linux-2.6 $ GIT_PAGER= time git grep sched_fair >/dev/null 0.34user 0.94system 0:01.30elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+7548minor)pagefaults 0swaps

$ find . -name .git -prune -o -type f | xargs perl -pi -e 's/\t/ /g' $ git-commit -a -m de-tabify $ git-repack -a -d $ GIT_PAGER= time git grep sched_fair >/dev/null 0.42user 1.06system 0:01.54elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+7591minor)pagefaults 0swaps

It's actually about 16%.

Gah, I can't believe I've not only been sucked into a tab vs spaces discussion, but now I've actually wasted time doing a performance comparison on it.

As an aside, that commit was enough to trigger a "git-gc --auto", which was my first experience with it. It's actually kind of annoying (especially since I was about to repack -a -d).

-Peff