log -g --reverse horribly insane

log -g --reverse horribly insane

[Shawn O. Pearce]

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.

Re: log -g --reverse horribly insane

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> 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.