On Wed, 17 Oct 2007, David Kastrup wrote: > Luke Lu <git@xxxxxxxxxx> writes: > > > But I still haven't seen any compelling arguments against the "all > > space" case, other than "people will screw it up into mixed spaces", > > which is really a straw man, as many multi-platform projects > > enforced the all-space policy easily by using a pre-commit hook in > > maintainers' repository. > > All-space indentation renders the binary delta algorithm git uses for > compression of packs slow and partly inoperative (all sequences of 16 > spaces share the same finger print, and the number of identical finger > prints for which the file information is kept is reduced to 64). But sequences of 16 spaces are unlikely to land on 16-byte boundaries all the time in the file so adjacent data to those 16-space blocks will still provide good hashing. > > The only downside of all-space is a moderate space bloat in source, > > which is insignificant, all things considered. > > It will also slow down git's packing and make it produce worse > results. If that was effectively the case then it is Git that had to be fixed and not the way people write code. Git should cope with the data it is fed and not the other way around. And this is completely orthogonal to the policy of using hard tabs or spaces in source code, so I'm clearly _not_ providing any argument to that discussion one way or the other here. Nicolas - 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
