Thread (9 messages) 9 messages, 3 authors, 2016-06-15

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

From: Stephen R. van den Berg <hidden>
Date: 2016-06-15 22:44:36

Junio C Hamano wrote:
"Lars Hjemli" [off-list ref] writes:
quoted
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.
quoted
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.
I agree that Lars' patch prevents parts of the tree to go "dark" (so did
my patch).
However, without either patch, that implies that the current --first-parent
code has a high probability of obscuring parts of the tree depending on
traversing order (in any tree which contains at least one merge).

So, I'd say, since the current code does not and cannot work reliably
for anyone specifically using --first-parent (with every merge
encountered, the probability of correctness is multiplied by 0.5 at
most/least), you are going to do them a favour anyway by fixing the code,
then why not simplify the convolution and make the code rock-steady (and
implement my patch)?

Anyone using --first-parent in production now has an embarrassingly high
probability of missing commits in his generated lists (I know that I
noticed the problem within 5 minutes from actually trying to use the
flag to get meaningful output).  So fixing and simplifying the code now
is rather unlikely to create any more surprises than the current code
already presents to existing users (if any).
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg.

What if there were no hypothetical questions?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help