Michael Witten <mfwitten@xxxxxxx> wrote: > On 16 Oct 2007, at 5:20:14 PM, Robin Rosenberg wrote: > > >So all this series does is... making it harder to follow the history? > > If you follow the history solely on patches. `git-blame -w` can probably punch through the indentation change just fine to find the older history. But it does make `git log -p` damn ugly to read at this point in history. And if you forget the -w to git-blame, well, then you are really in for some fun for a few minutes. Lets not mention pickaxe noticing strings removed+added in this patch either. > >Ack for removing the --binary, the rest is just noise > > I think fixing the tabs is more important than removing --binary. > > It's clear the the entropy of tabulation increases over time; > the tab patch acts as a buffer to reconstruct a clean signal. Sorry, but I have to say I agree with Robin here. The tab patch is large, ugly, and provides relatively little value in comparsion. The first rule of git development typically is "any change is bad". Because anything that is already written can be assumed to already be tested and in use by someone. Breaking that is bad, as then they have a bad experience with git. There needs to be a really good reason behind a change, like the existing code is already not functioning according to its documented behavior due to a corner case input. Such things should be changed. I'm not going to apply the indentation change patch to my tree. You can try to resubmit it through Junio after he's back online and accepting patches. -- Shawn. - 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
