On Tuesday 2007 February 27 20:32, Junio C Hamano wrote: > * refs.c::log_ref_write() gets an optional log message and > writes it after the GMT offset, with an explicit "\t", so > this is not it, either. Your mention of tabs set off alarm bells in my head. I had another look at the files with "less -S" instead of tail and lo-and-behold, the tab is shown. Panic over. This isn't a fault with git. Stop reading now if you're only interested in git. It's some weird interaction with tabs and my terminal and those particular line lengths. The two repositories I was comparing logs in have different email addresses for me, so the column at which the tab activates is different. Bizarrely, in one case the tab appears swallowed, in the other it appeared correctly. -- time passes --- It seems like a fault in terminals in general to me (perhaps it's specified in a standard somewhere, so everyone just implements it): if a tab is output in the last column of the terminal, it's just swallowed - no space at all is shown. It's easily repeatable. * Open an xterm * Resize it so that it's 50 columns wide. * echo -e "0xxxxxxxxx1xxxxxxxxx2xxxxxxxxx3xxxxxxxxx4xxxxxxxx\t5xxxxxxxxx" * Notice that the "5" is not on the next line where one might expect, but is in column 49 Am I wrong to think this is wrong? I've always thought that there was an implicit tab just off the end of a terminal line, which effectively brings the output to the next tab stop (i.e. column 0 of the next line). 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