On Tuesday 2007 March 13 14:42, Johannes Schindelin wrote: > And of course the next guy will have the reverse problem, because he typed > <TAB><SPACE> instead of <SPACE>*5. What do you tell _him_ after "fixing" > this issue? "Do as _I_ do"? That's basically what you're telling me by saying I can't have that change. But as it happens, no I wasn't doing this as a "do it my way" kind of thing. As it happens I /like/ tabs in my source code. However, this isn't source code. Let's forget my own problem - I was only offering it as backstory. Consider a log message with no additional comments about the conflicts. The current output looks like this: Conflicts: \tfile1.c \tfile2.c Now, view this message on the terminal with git-log, now view it in gitk, now view it in qgit, now view it in git-gui. All of these could be set for different tab widths, and will hence display the log message differently. git-merge has to pick one or the other - tabs or spaces - for me, I'd rather pick the one that means the message displays the same regardless of what the author of the viewer/terminal thought tabs should be set to that day. I'd also prefer that when others view the log there is more chance that they'll see the same as I do. Of course, there is nothing we can do if a log message author chooses to put tabs in - but at least if git uses spaces the choice isn't already made. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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