"Lars Hjemli" <hjemli@xxxxxxxxx> writes: >> - 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. > >> - 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
