Improves git object cache

[arturcic]

Follow up for #4681

[HHobeck]

@pvanbuijtene: Thank you for your contribution and the work you have done.

I have following remarks/suggestions:

• The classes Commit, Branch and so on are wrapper classes around the LibGit2Sharp objects. I would say the wrapper classes should not have a reference to GitRepostory. Is it an idea to extract the functionality of caching in a separate class and use this instead?
• Because of the nature of a wrapper class I would expect that the LibGit2Sharp objects are reused as well and the hash code is the same (otherwise we would have still a memory problem). Probably you can use the hash code instead of using an arbitrary string (needs to be tested).

[arturcic]

@pvanbuijtene: Thank you for your contribution and the work you have done.

I have following remarks/suggestions:

• The classes Commit, Branch and so on are wrapper classes around the LibGit2Sharp objects. I would say the wrapper classes should not have a reference to GitRepostory. Is it an idea to extract the functionality of caching in a separate class and use this instead?
• Because of the nature of a wrapper class I would expect that the LibGit2Sharp objects are reused as well and the hash code is the same (otherwise we would have still a memory problem). Probably you can use the hash code instead of using an arbitrary string (needs to be tested).

That was my idea to move the functionality from the GitCache class back into the GitRepository as I think the repository wrapper should handle the caching mechanism as it's the abstraction of the database which maintains the collections and the cache, but we can reconsider that

[pvanbuijtene]

Happy to help :)

@arturcic as I understand you will implement the suggestions, feel free to ping me in case you want to have some changes tested against a repository causing issues.

[arturcic]

@pvanbuijtene thank you, yeah, I implemented the suggestions so far in this PR, but it's a draft for now, I want to test caching the other collections as well before having this merged

[arturcic]

@pvanbuijtene do you have the time to test this PR on the big repository you have and compare?

[pvanbuijtene]

@arturcic sure, the changes seem to have introduced some additional memory usage:

main: peak around 380MB

this pr: peak around 725MB

[arturcic]

@arturcic sure, the changes seem to have introduced some additional memory usage:

main: peak around 380MB

this pr: peak around 725MB

btw what are you using for the memory usage analysis?

[pvanbuijtene]

It's the standard monitoring when running it from Rider.

Here's some more detailed information from a dotMemory snapshot taken roughly at the peak:

main:

pr:

[arturcic]

It's the standard monitoring when running it from Rider.

Here's some more detailed information from a dotMemory snapshot taken roughly at the peak:

main:

pr:

Ok I'm also using Rider, I will have to check it out as well, thanks

[pvanbuijtene]

I will also do a check with the anonymized repo to see if the object counts are similar, this way there might still be a way to verify things with that repo.

[pvanbuijtene]

Here are the results with the anonymized repo, not exactly the same but it looks quite similar. So I would assume you should be able to get similar results when comparing main vs. this pr.

main:

pr:

[arturcic]

@pvanbuijtene mind to have a new run on memory usage for main and PR branch against your original big repo?

[Copilot]

Pull Request Overview

This PR refactors the git object caching mechanism by introducing a dedicated GitRepositoryCache class to centralize object wrapping and caching. The changes improve code organization and maintainability by extracting caching logic from the GitRepository class into a specialized cache component.

Key Changes:

• Introduces a new GitRepositoryCache class to centralize caching of git objects (branches, commits, tags, remotes, references, refspecs)
• Removes the IGitObject interface and moves its properties directly to ICommit
• Renames Refs property to References throughout the codebase for consistency
• Updates collection classes to use the new caching mechanism instead of creating objects directly

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
GitRepositoryCache.cs	New cache class implementing centralized caching logic for git objects
GitRepository.cs	Refactored to use GitRepositoryCache and lazy initialization for collections
Commit.cs	No longer inherits from GitObject; implements ICommit directly with Id/Sha properties
IGitObject.cs	Removed interface; properties moved to ICommit
ICommit.cs	Now contains Id and Sha properties directly instead of inheriting from IGitObject
IGitRepository.cs	Renamed Refs property to References
Branch.cs, BranchCollection.cs	Updated to use GitRepositoryCache instead of GitRepository
Tag.cs, TagCollection.cs	Updated to use GitRepositoryCache instead of GitRepository
CommitCollection.cs	Updated to use GitRepositoryCache instead of GitRepository
Remote.cs, RemoteCollection.cs	Updated to use GitRepositoryCache instead of GitRepository
Reference.cs, ReferenceCollection.cs	Updated to use GitRepositoryCache instead of GitRepository
RefSpec.cs, RefSpecCollection.cs	Marked RefSpec as sealed; updated to use GitRepositoryCache
RepositoryStore.cs	Updated method signature to use ICommit instead of IGitObject
GitPreparer.cs	Updated all Refs references to References
PublicAPI files	Updated shipped/unshipped API surfaces

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull Request Overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arturcic]

@pvanbuijtene mind to have a review as well?, please also attach the new memory consumption data you see on your big repo.

[pvanbuijtene]

With the restricted knowledge I have of this repository... looks good, ran it twice and the memory usage of the pr branch is slightly lower.

main:

pr:

[arturcic]

With the restricted knowledge I have of this repository... looks good, ran it twice and the memory usage of the pr branch is slightly lower.

main:

pr:

thanks @pvanbuijtene. I think I will merge this one then. Thanks once again for the initial work you've done.

[mergify]

Thank you @arturcic for your contribution!