Fix interaction between limited flag and sorting over resets

[mystor]

Sorted revwalks have their limited flag set because lazy revwalks, which are used when limited is not set since #4606, currently only handle GIT_SORT_NONE.

Revwalks persist their sorting over calls to git_revwalk_reset. However, the limited flag was unconditionally cleared during git_revwalk_reset, which would cause breakage.

This patch sets the limited flag for non-GIT_SORT_NONE revwalks in reset, and adds a test for the failing case.

I ran into this bug while making a version of pygit2 with the mailmap changes from #4586, as pygit2 tests started failing.

[ethomson]

Thanks, @mystor! @carlosmn can you review this quickly?

[carlosmn]

Where we do we get the idea that the sorting should persist? That sort of worked many years ago but the git_revwalk_reset function is there to re-use the walk structures and caching and should reset all of the state and you need to provide it with all of the information as though you had created a new one.

[mystor]

Not sure. I was surprised that it persisted, but that appears to match the current behavior and the behavior tested by pygit2 in a test. It would be perfectly reasonable to change to not persisting as well.

[pks-t]

I agree with @carlosmn. The documentation of git_revwalk_reset states that:

This will clear all the pushed and hidden commits, and leave the walker in a blank state (just like at creation) ready to receive new commit pushes and start a new walk.

So there really shouldn't be any difference between a newly allocated revwalk via git_revwalk_new and a resetted one. So I guess the right fix would be to set walk->sorting = GIT_SORT_NONE in git_revwalk_reset, as well.

[mystor]

Swapped the behaviour change over

[ethomson]

Thanks, @mystor!