Skip to content

Fix over recursion of git serve

Warren Gifford requested to merge iv/fix-walking-too-far into main

Created by: varsanojidan

Fixes https://github.com/sourcegraph/customer/issues/1210

So there was some weird behavior circling around this change.

Before the change:

  • When searching for repos, we would only continue recursing on bare git repos, looking for subprojects underneath them
  • Our tests were testing as if we were recursing on non-bare git repos (even though we weren't in the code), and they were passing because of the strange way we were initializing the non-bare git repos in our tests (--bare with a path to the .git directory)
  • Our tests would pass, but functionality wise we would never continue searching for git repos once we hit our first .git directory

After the change:

  • The change corrected the behavior of the code to match what we were testing
  • The extra recursion after the change, now that we check every single directory to see if its a repo, caused an exponential hit in performance to the server i.e. serving 100 avg sized repos and querying http://localhost:3434/v1/list-repos takes several minutes to return as opposed to a couple of seconds.
  • This performance hit directly affected the issue linked at the top of the thread.

In this PR I have removed the support for subprojects making the code return the moment it finds either a git or a bare git repo. My assumption here was that because it was broken before this change, there didn't seem to be much of a need for us to support subprojects, and once reverted, the performance is now back to where it was previously.

I am open to feedback on if it is important for us to server subprojects this way, in which case we would need to think about a significantly more performant way of doing so.

Test plan

Tested manually to validate the improved runtime. Existing non-removed tests pass.

Merge request reports