Shallow clone for better performance

We regularly see response times from our config server of 15-25 seconds. We have on average ~30 requests with response times > 15s each day. These high response times happen when config server is fetching from one of our repos and there are updates in that repo. There are often updates since any time someone creates a new feature branch and makes a change to it, that is an update.

This repo has many, many files in it (for multiple applications). Some of the files have 1000s of lines. But the biggest culprit, I believe, is that it has a huge amount of history.

We are looking at potentially breaking it into multiple repos (and use the new composite repos feature for shared configs). That will help. However, the team wants to migrate the history over to the new repos, so now we will have multiple repos with huge history instead of just one.

We were hoping that we could improve performance by configuring the config server to do a shallow clone of the repos (e.g. git clone --depth 1) . There doesn't appear to be an option for that right now.

The Request: I'd like to request you to enhance the config server to allow for optionally doing a shallow clone.

I realize this might not be feasible. I'm nearly a novice with git, and not sure if such a shallow clone would "play nicely" with the existing config server repo wrt to updates, etc. Also, it appears that the jgit library itself does not expose an option for doing a shallow sync (though I could have missed something).

If not feasible, or not something that might be implemented in the next couple of releases, is there an existing alternative option that might help improve our config server's response time? (Even if this feature does get into the queue, is there something I can do right now to improve performance?)

Note: We're currently at Greenwich.SR3.

Start at the config server's repository clone and update path, then inspect how its JGit integration handles synchronization. Determine whether an optional shallow clone remains usable when repositories receive updates and how it affects response times. Done means the behavior, configuration, and update implications are clearly defined before implementation.