Funny reflog has missing space

Hello,

I've just peeked in my reflog (tail .git/logs/HEAD), and found something strange:

72160ca5c05fab4fbd3c24c9b13cbd0651b60532 ca7b20e2677960cfc52c525b8f8bdf12ce79176b Andy Parkins <long@emailaddress.com> 1172589175 +0000commit: Log message goes here

Notice that there is no space between the "+0000" and the "commit". This is true for every item in this log and every log in this repository.

Over in another part of the forest, I've got my git repository. This is fine, and has the space where I would expect. The only difference I can see is that in one I'm using my long work email address, and in the git one I'm using my shorter gmail address.

Is this normal?  "git-reflog show" works fine in both cases.

Andy

Hi,

On Tue, 27 Feb 2007, Andy Parkins wrote:

Yes, because Junio made me change the code to not barf on a missing space.

Thanks Junio, Dscho

Andy Parkins <andyparkins@gmail.com> writes:

It is not. It would be good to find out who puts corrupted entry.

Junio C Hamano <junkio@cox.net> writes:

Hmmm. I am puzzled. The only two low-level locations I know of that writes into reflog are:

 * builtin-reflog.c::expire_reflog_ent() copies existing log
   entry, which are parsed out, after reformatting it.  It has
   an explicit "\t" in the format string, so it is not it.

 * 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.

On Tuesday 2007 February 27 20:32, Junio C Hamano wrote:

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