Feature: Use installed git.exe instead of libgit2

[heftymouse]

What feature or improvement do you think would benefit Files?

Having this as an option would allow Files to easily support the full range of Git features, including automatically respecting the user's Git settings, using any authentication methods they have already configured, and pushing to ssh remotes. This is a fairly common way of implementing Git support, seen in software like vscode. Files can fall back to libgit2 for basic support if Git is not already installed (unlikely on a developer's machine)

Requirements

• Introduce an IGitService abstraction and refactor the existing GitHelpers implementation to use it
• Implement existing Git operations through git.exe and use this implementation if git.exe is found
• Add configuration options

Files Version

3.8.13

Windows Version

10.0.27774.1000

Comments

No response

[Lamparter]

I wrote just the thing for this!
Might need a bit more work, but it's a start.

[0x5bfa]

I remember someone told me porcelain is better, perhaps you, and I think this is a good idea. Here's my thoughts:

I have been thinking about this being a standalone class like below and I think this would be instantiated through GitRepositoryFactory static class (e.g. GetOrCreate()) to retrieve one identical instance per the same git repo among tabs, panes and windows. This way prevents us from putting string path in each method.

public static class GitRepositoryFactory
{
    private Dictionary<string, GitRepository> lookupTable = [];

    public GitRepository? GetOrCreate(string path) {}
}

public partial sealed class GitRepository : IDisposable
{
    public GitRepository(string rootPath) {} // Ideally, not string but IFolder in the future.
}

I still haven't evaluate how difficult this is and how suitable this is so I can't say which is better for now but IGitRepositorySevice would work in this current codebase and be easier.

[Lamparter]

@yaira2 what do you think?
I have a working IGitService implementation that I can implement here quite easily if you like.

[yair100]

@yaira2 what do you think? I have a working IGitService implementation that I can implement here quite easily if you like.

I'm not sure we'll be able to copy directly from the project you linked, since we have different method names, but the idea sounds good.

[Lamparter]

@yaira2 sure, but is it still something you'd like to move forward with?

[yair100]

We can move forward with the interface. Please let me know before doing anything beyond that🙂

[Lamparter]

Roadmap for migrating GitHelpers to a DI service

• GetGitRepositoryPath Code Quality: Moved GetGitRepositoryPath operation into Git abstraction #18435
• GetOriginRepositoryName Code Quality: Moved GetOriginRepositoryName operation into Git abstraction #18438
• GetBranchesNames Code Quality: Moved GetBranchNames operation into Git abstraction #18440
• GetRepositoryHead Code Quality: Moved GetRepositoryHead operation into Git abstraction #18505
• Checkout Code Quality: Moved Checkout operation into Git abstraction #18669
• CreateNewBranchAsync Code Quality: Moved CreateNewBranchAsync operation into Git abstraction #18724
• DeleteBranchAsync Code Quality: Moved DeleteBranchAsync operation into Git abstraction #18726
• ValidateBranchNameForRepository Code Quality: Moved ValidateBranchNameForRepository operation into Git abstraction #18727
• FetchOrigin
• PullOriginAsync
• PushToOriginAsync
• RequireGitAuthenticationAsync
• IsRepositoryEx
• GetGitInformationForItem
• RemoveSavedCredentials
• GetSavedCredentials
• InitializeRepositoryAsync
• GetRepoInfo
• IsValidRepoUrl
• CloneRepoAsync Fix: Fixed an issue where private repos could not be cloned #18734

---

• Init Code Quality: Introduced an abstraction for Git operations via IVersionControl #18040
• Private methods Code Quality: Moved all private operations into Git abstraction #18441
• IsExecutingGitAction et al. Code Quality: Refactored LibGit2 integration as a DI service for future-proofing #18679