# log -g --reverse horribly insane 2 messages from 2007-08-19 to 2007-08-19. Participants: Shawn O. Pearce, Junio C Hamano. Thread: https://gitlist.dev/t/9573 ## Shawn O. Pearce, 2007-08-19 08:56 Subject: log -g --reverse horribly insane Message-ID: <20070819085624.GU27913@spearce.org> URL: https://gitlist.dev/e/20070819085624.GU27913%40spearce.org ``` OK, I'm just too tired to find this on my own right now. I'll try again later after I get some sleep, but maybe someone with a different sleeping pattern than me will find and fix this before I arise... git log -g --reverse --pretty=oneline Does not produce anything useful. Results are ranging from getting a single line with upwards of 50 commits on it and a corrupt log message to lines with no log message and only one commit, even though the non --reverse output has over 200 results to report. git log -g --reverse Does not show the reflog message headers, but is otherwise fine. So it shows the history according to the reflog (I think that's what I saw) but isn't showing the data I asked for with -g. Results are the same for HEAD's reflog as for any other branch in my tree. Basically its nutso. I think we need to either support -g --reverse combination properly, or we need to disallow it. The current behavior is uh, not user friendly. -- Shawn. ``` ## Junio C Hamano, 2007-08-19 09:09 Subject: Re: log -g --reverse horribly insane Message-ID: <7v8x87dh5r.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v8x87dh5r.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20070819085624.GU27913@spearce.org> ``` "Shawn O. Pearce" writes: > OK, I'm just too tired to find this on my own right now. I'll try > again later after I get some sleep, but maybe someone with a > different sleeping pattern than me will find and fix this before > I arise... > > git log -g --reverse --pretty=oneline I would have to say that "-g" support was hacked into the normal revision traversal machinery in such a way to minimize the amount of changes, without refactoring the two completely different traversal machineries separate to make the resulting code maintainable. Ideal refactoring would require quite a lot of changes, unfortunately. I would say it probably would make sense to make the two options incompatible for now. ```