Funny reflog has missing space

Funny reflog has missing space

[Andy Parkins]

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
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Funny reflog has missing space

[Johannes Schindelin]

Hi,

On Tue, 27 Feb 2007, Andy Parkins wrote:

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

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

Thanks Junio,
Dscho

Re: Funny reflog has missing space

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

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

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

Re: Funny reflog has missing space

[Junio C Hamano]

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

> Andy Parkins <andyparkins@gmail.com> writes:
>
>> 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".
>> ...
>> Is this normal?  "git-reflog show" works fine in both cases.
>
> It is not.  It would be good to find out who puts corrupted
> entry.

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.

OT: Funny tab behaviour on terminals

[Andy Parkins]

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@gmail.com