Re: [PATCH v2] revision.c: really honor --first-parent

"Lars Hjemli" [off-list ref] writes:

quoted

 - My original patch did just that, it simplified the code to make sure
  that all other parents beside the first parent are ignored when
  walking the tree.

Except for the case where the first parent had been already SEEN; then
it would continue to test the next parents until one was found which
was not already SEEN and _that_ parent would be treated as if it was
first. And as Nanako showed, a simple `git rev-list HEAD^..HEAD` marks
both HEAD and HEAD^ as seen. When combined with --first-parent, the
result (with your patch) is that HEAD^2 is treated as the first
parent. With my patch on top of yours, the walk stops as HEAD^, which
is what we probably both want.

quoted

 - Your code now doesn't simplify the (IMO) convoluted walk, and still
  marks things as seen, even though in the first-parent case, these
  commits are not really seen at all.  It implies that your code
  generates differing output, depending on the merges present.

I don't think so. My code should neither follow nor mark as SEEN any
parent but the first (but I could obviously be wrong).

A major part of the "convoluted walk" is the (il-)logic that skipped
earlier SEEN parents and treated the first unseen one as if it was the
first parent, which is not exactly Stephen's fault.  It was placed by
yours truly in the very original code but it was done without much
thought.

I think your patch is the correct fix for that convolution, regardless of
the traversal order stability issue Stephen mentions.