👀 Proposal: Integrate SwiftGitX as an Alternative to the Current Git Implementation

[ibrahimcetin]

I would like to propose integrating SwiftGitX into CodeEdit as an alternative to the current GitClient implementation that relies on executing Git shell commands.

Background

Currently, CodeEdit uses a GitClient class that wraps Git shell commands by spawning subprocesses, capturing output, and then parsing the results to build models. While this approach works, it has some limitations:

• Performance Overhead: Each Git operation requires spawning a new process, which can be slow compared to directly interacting with Git data structures.

• Error Handling: Parsing command-line output can be fragile and error-prone, as Git’s output format may change between versions.

• Dependency on Git Executable: The current approach requires the Git binary to be installed and available in the system’s PATH.

About SwiftGitX

SwiftGitX is a Swift-native wrapper around libgit2, providing a structured and efficient way to interact with Git repositories programmatically. Key advantages include:

• Direct Interaction with Git Repositories: No need for shell commands; everything is handled in Swift.

• Better Performance: By avoiding process spawning and output parsing, operations are faster and more efficient.

• No External Dependencies: SwiftGitX does not require an external Git installation; it can be added as a Swift package and works out of the box.

• Well-Tested: The library includes more than 100 unit tests and 90% test-coverage, ensuring reliability and stability.

Proposed Plan for Incremental Integration

To avoid a large and disruptive refactor, I propose an incremental approach:

1. Introduce SwiftGitX as an optional dependency – Add SwiftGitX to the project while keeping the existing GitClient implementation.

2. Implement Core Functionality – Start by replacing a small subset of Git operations (e.g., getting repository status, listing branches) to validate the integration.

3. Expand Coverage – Gradually replace more Git operations with SwiftGitX where it provides clear advantages.

4. Evaluate and Optimize – Compare performance, reliability, and maintainability before considering a full migration.

Next Steps

I’d love to discuss this proposal with the maintainers and contributors of CodeEdit. If this approach sounds reasonable, I can start working on the initial integration and provide PRs step by step.

Looking forward to your feedback!

[hi2gage]

Hey @ibrahimcetin, I saw your post in Discord and wanted to take a look! I also left some comments up on the draft PR.

Note: I'm not one of the maintainers of this project so these are all personal thoughts.

A couple of thoughts:

Dependencies:

Adding external dependencies always carries some risk. Are you (the main maintainer from what I can tell) committed to keeping SwiftGitX updated and addressing potential issues? What’s the long-term maintenance plan? If we ever need to roll back, how disruptive would it be? Would we end up tightly coupling the project to SwiftGitX, or could we maintain a level of abstraction to make switching easier? One advantage of our current approach is full control over the implementation. Not saying we shouldn't do it, we just need to be aware of the risks.

Also another thing I'll mention is that the project currently has 31 dependencies (5 of them being internal). Looking at the SwiftGitX project it looks like there are 13 resolved dependencies including libgit2 which is fine but if all of a sudden versions get out of wack package resolution could get tricky especially with SyntaxSwift as dependency.

Test Coverage:

Love the 90%+ test coverage but I ran the tests l noticed that 21 of them were failing. I think having high passing test coverage makes me feel much more confident adding external dependencies if all of the tests were passing consistently. Adding some CI / test test coverage on your repo would be great!

###Incremental Integration:
I agree that a full refactor all at once isn’t ideal. A few alternative approaches:

• Introduce an abstraction layer – Define a protocol that both the current implementation and SwiftGitX can conform to, allowing us to switch via config without removing working code.
• Use mapping layers – Keep the current types but map SwiftGitX structs to them under the hood, reducing blast radius.
• Redesign from the ground up – Since CodeEdit is still in alpha, this could be a chance to rethink the source control UI and architecture for better long-term maintainability.

Really excited about this idea, SwiftGitX's portability and type safety would be major wins!

[ibrahimcetin]

Thanks for taking the time to review and share your thoughts! I really appreciate the detailed feedback. I'll try my best to answer your questions.

Long-Term Maintenance & Dependencies

Are you (the main maintainer from what I can tell) committed to keeping SwiftGitX updated and addressing potential issues?

Yes, I am.

What’s the long-term maintenance plan?

I've created a draft roadmap for it, you can checkout.

If we ever need to roll back, how disruptive would it be? Would we end up tightly coupling the project to SwiftGitX, or could we maintain a level of abstraction to make switching easier?

This migration would likely result in tight coupling with SwiftGitX, but I believe this is actually beneficial. SwiftGitX is already well-structured, and trying to create an additional abstraction layer might lead to unnecessary duplication.

That said, I want to mention that last year I migrated CodeEdit to SwiftGitX on my local except push and pull features. Therefore, I suggest incremental migration approach.

Additionally, from what I’ve seen, the current Git implementation seems to be in a stalled state, with many // TODO: Implementation Needed comments. Managing the existing Git implementation is becoming increasingly complex, and I believe that in the long run, we should separate the Git implementation from the project itself to make it more maintainable. Whether we use SwiftGitX or another approach.

Also another thing I'll mention is that the project currently has 31 dependencies (5 of them being internal). Looking at the
SwiftGitX project it looks like there are 13 resolved dependencies including libgit2 which is fine but if all of a sudden versions get out of wack package resolution could get tricky especially with SyntaxSwift as dependency.

I think this count includes development dependencies like SwiftLint, SwiftFormat, and Docc, which would not be included in the CodeEdit project. For the projects, SwiftGitX has only one dependency: libgit2.

Test Coverage

Love the 90%+ test coverage but I ran the tests l noticed that 21 of them were failing. I think having high passing test coverage makes me feel much more confident adding external dependencies if all of the tests were passing consistently. Adding some CI / test test coverage on your repo would be great!

I’m glad you appreciate the high test coverage. All tests should be passing, so if you could share details about the failing tests, that would be really helpful.

SwiftGitX already has a GitHub Actions workflow configured to run all tests. It’s currently failing because xcode-latest does not include the Swift Testing package, but this is not a major issue and can be resolved.

Incremental Integration Approach

I agree that a full refactor all at once isn’t ideal. A few alternative approaches:

Introduce an abstraction layer – Define a protocol that both the current implementation and SwiftGitX can conform to, allowing us to switch via config without removing working code.
Use mapping layers – Keep the current types but map SwiftGitX structs to them under the hood, reducing blast radius.
Redesign from the ground up – Since CodeEdit is still in alpha, this could be a chance to rethink the source control UI and architecture for better long-term maintainability.

I believe we can migrate most of the existing implemetation to SwiftGitX while keeping some parts of the current implementation where necessary. SwiftGitX is still missing some key features, such as pull, merge, and rebase, so we shouldn't fully remove the existing Git logic yet.

Why SwiftGitX?

Instead of continuing to develop the current Git implementation, which is becoming complex and hard to maintain, I believe that wrapping libgit2 is a more structured and maintainable approach.

I developed SwiftGitX, but it’s still evolving, and missing features can be worked on collaboratively. My goal is to make the Git integration in CodeEdit more robust and future-proof, and I believe SwiftGitX provides a solid foundation for this.

Let me know your thoughts!