cc @DaedalusG

Codenotify: Notifying subscribers in CODENOTIFY files for diff 8f52cae...e5b55ae.

Since you've all gathered here, out of curiosity: what was the original reason for introducing sg maintenance? why is it better than GCAUTO?

TLDR: it speeds up git-log operations for very large repos. EG, without it, displaying git history (last 5 commits of a file) becomes very slow. At the time we introduced this, git didn't expose the right flags/config on the porcelain level. I think it is worth re-checking this and maybe contribute to git rather than writing our own wrapper around plumbing commands.

Here is some backround

• benchmarks
• comments in the code

@mrnugget Additionally around the same time this was being developed we were trying to resolve an issue in which a customer was experiencing failures in indexing their monorepo, in which zoekt would fail to fetch from gitserver.
https://github.com/sourcegraph/customer/issues/586

Ah, yes good data point. Limiting the memory with -window-memory definitely helped.

I guess the decision is between which kinds of problems are more acceptable for customers. I believe repo corruption tops everything, especially for monorepo customers where re-cloning is expensive. By disabling sourcegraph maintenance we will get more complaints about MEM and slow UI. At least we know how to limit MEM, because -window-memory is exposed as config parameter.

For anyone who wonders what that means with respect to their Sourcegraph installation:

This change will roll out with Sourcegraph 4.1.

Overall, this change will increase stability for all customers.

Customers with large monorepos have most likely already disabled sg maintenance, either because they ran into problems or because they were advised by their CE.

For customers with large monorepos that have sg maintenance enabled, git operations based on git-log will most likely run slower now. An example is the history of the last commits displayed at the bottom of the tree view. The core search experience, however, is not affected. If they prefer to leave sg maintenance enabled (NOT RECOMMENDED), they have to explicitly set "SRC_ENABLE_SG_MAINTENANCE=true" and "SRC_ENABLE_GC_AUTO=false" for gitserver.

In some cases, gitserver might not be able to run garbage collection because of lack of memory. This might manifest itself by a failed fetch or clone. In this case we advise customers to set git config pack.windowMemory 100m either globally or for the repo in question on gitserver.

Customers with small to medium sized repositories won't notice a difference.