[RFH] revision limiting sometimes ignored

On Sat, Feb 02, 2008 at 10:00:54PM -0500, Jeff King wrote:

OK, there is definitely a bug here, but I'm having some trouble figuring out the correct fix. It's in the revision walker, so I have cc'd those who are more clueful than I.

You can recreate a problematic repo using this script:

-- >8 -- mkdir repo && cd repo git init

touch file && git add file
commit() {
  echo $1 >file && git commit -a -m $1 && git tag $1
}

commit one commit two commit three git checkout -b other two commit alt-three git checkout master git merge other || true commit merged commit four -- 8< --

So a fairly simple repo, but with the key element that it contains a merge. Now try this:

  git log one --not four

You get the 'one' commit, even though it should be removed by "--not four". But if you try this:

  git log one --not two

you correctly get no output.

It seems that in limit_list, we do two things:
  - first add the 'one' commit to the new list (since we process it
    before it gets marked uninteresting)
  - then traverse from 'four', marking commits and their parents as
    uninteresting as we go

However, the traversal seems to have trouble going over the merge. We add the parents, but we end up marking them all as uninteresting, and the everybody_uninteresting() optimization triggers, quitting the limit before we have a chance to reach back to 'one' and mark it. The patch below fixes it, but I'm very uncertain whether there is something else going on that I'm missing that should be handling this case.

---