count_recursive can hang in a "git bomb" repo, even with a limit

[jorendorff]

count_recursive with a limit argument will hang if you run it in a "git bomb" repo that contains quadrillions of directories and not enough files to reach the limit.

This means the method can't really be used to enforce limits in code that runs on untrusted repos.

[jorendorff]

It's not super obvious what the right fix is.

• Make count_recursive count both files and directories. That would be a breaking change.
• Make the method return limit if it visits that many directories, even if it hasn't found any files yet. This is odd because the method can return a number greater than the number of files in the repo; the limit isn't just truncation.
• Make the method stop after visiting limit trees, and return whatever it got. But then it may return a number smaller than limit for a repo that is too big to check out, a misleading result.

EDIT to add:

• Cache results per tree, so that walking a "git bomb" tree actually finishes, giving the right answer, without needing to count to a quadrillion. Sweet, but it would regress performance a bit in the normal case.

[josantoniolagunesquiroz-maker]

[josantoniolagunesquiroz-maker]

[josantoniolagunesquiroz-maker]

[jorendorff]

@carlosmn What do you think about this? If any approach seems acceptable, I can patch and test.

If Rugged has a policy of not including workarounds for bad repos, let's go ahead and close it.

[carlosmn]

You should be able to add an extra parameter to limit the max number of trees we're willing to go look at. That wouldn't change the current API but it also wouldn't fix any existing uses.

[jorendorff]

That makes sense. For now, I'll leave this open and fix my downstream code instead.

[heitzmandrew]

Kool

[carlosmn]

Fixed via #996