Any further comments? I'm more than willing to implement this, but I won't bother if there's no chance of getting it accepted as a patch. Does no one else feel like at least having the option to enforce whitespace consistency in git is a good thing? If not, I guess I'll just muddle along without this feature instead of implementing it. On Wed, Oct 15, 2008 at 2:18 PM, Stefan Karpinski <stefan.karpinski@xxxxxxxxx> wrote: > That's not what I would call a "crazy" mix of tabs and spaces, but > rather a *sane* mix of tabs and spaces. That can consistently be > reproduced, and is in fact what the spaces_to_tabs function included > above produces. The sane consistent formats as I see it are: > > 1) use spaces for everything > 2) use tabs for indentation, spaces for everything else > 3) use tabs for indentation and alignment > > If you know the tab size, you can reproduce any of these from the > others, except that #3 is a little tricky since there's places where > the tab/space issue can be ambiguous. I actually think that keeping > the repo version with tab-based indentation is a very sane thing to > do. However, I'd still like to be able to edit the files using soft > tabs, largely because any program that doesn't know what my tab size > should be applies its own interpretation and makes the code look > terrible (think terminal output for diff, cat, less, etc.) > > On the other hand, a *crazy* mix of tabs and spaces is where some > indentation is done with spaces while other indentation is done with > tabs. Even crazier is a single line where the indentation is a mixture > of tabs and spaces. I think that just about everyone can agree that > this is not only crazy, but evil and is the kind of thing one really > wants to avoid in a code base. Unfortunately, when developers disagree > on their standard settings, it's very, very hard to avoid precisely > this kind of mess. My idea is to enable git to prevent this sort of > insanity if configured to do so. -- 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
