# Funny reflog has missing space 5 messages from 2007-02-27 to 2007-02-28. Participants: Andy Parkins, Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/6995 ## Andy Parkins, 2007-02-27 15:29 Subject: Funny reflog has missing space Message-ID: <200702271529.13258.andyparkins@gmail.com> URL: https://gitlist.dev/e/200702271529.13258.andyparkins%40gmail.com ``` Hello, I've just peeked in my reflog (tail .git/logs/HEAD), and found something strange: 72160ca5c05fab4fbd3c24c9b13cbd0651b60532 ca7b20e2677960cfc52c525b8f8bdf12ce79176b Andy Parkins 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 ``` ## Johannes Schindelin, 2007-02-27 15:59 Subject: Re: Funny reflog has missing space Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0702271659260.22628%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <200702271529.13258.andyparkins@gmail.com> ``` 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 ``` ## Junio C Hamano, 2007-02-27 19:30 Subject: Re: Funny reflog has missing space Message-ID: <7v4pp7flew.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4pp7flew.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200702271529.13258.andyparkins@gmail.com> ``` Andy Parkins writes: > Hello, > > I've just peeked in my reflog (tail .git/logs/HEAD), and found something > strange: > > 72160ca5c05fab4fbd3c24c9b13cbd0651b60532 > ca7b20e2677960cfc52c525b8f8bdf12ce79176b Andy Parkins > 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. ``` ## Junio C Hamano, 2007-02-27 20:32 Subject: Re: Funny reflog has missing space Message-ID: <7vslcrcpeg.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vslcrcpeg.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v4pp7flew.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Andy Parkins writes: > >> Hello, >> >> I've just peeked in my reflog (tail .git/logs/HEAD), and found something >> strange: >> >> 72160ca5c05fab4fbd3c24c9b13cbd0651b60532 >> ca7b20e2677960cfc52c525b8f8bdf12ce79176b Andy Parkins >> 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. ``` ## Andy Parkins, 2007-02-28 09:34 Subject: OT: Funny tab behaviour on terminals Message-ID: <200702280934.52650.andyparkins@gmail.com> URL: https://gitlist.dev/e/200702280934.52650.andyparkins%40gmail.com In-Reply-To: <7vslcrcpeg.fsf@assigned-by-dhcp.cox.net> ``` 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 ```