These are some thoughts on scenarios I'd like to support with version control integration.

Some specific scenarios that are important to enable:

• Seeing diff markers in the editor window for the files you are working with
• Seeing diff status in the explorer window for files you're working with, so that it's easy to determine if a file has staged changes
• Facilitate merging:
  • Quickly identify and move between files that have merge conflicts
  • Quickly move between merge-conflict markers
• Switch branches
• See active branch, along with changed files

These are primarily common problems across VCS providers. It'd be great if we could generalize these capabilities to work with different VCS providers, and allow a way to implement providers.

The 'provider' could be implemented as an interface - this is just a quick sketch of what a VCS Provider could look like:

export interface VersionControlProvider {

    // Events
    onBranchChanged: IEvent<BranchChangeInfo>
    onFileStatusChanged: IEvent<FileVersionStatus>
    onStagedFilesChanged: IEvent<StagedFilesStatus>

    // Given a workspace path, returns 'true' if the provider can provide
    // version control capabilities. For example, a `GitVersionControlProvider`
    // would look for the presence of a `.git` folder at the root.
    canHandleWorkspace(workspacePath: string): Promise<boolean>

    // Get the 'blame info' for a file - the per-line
    // information about a commit
    getBlame(filePath: string): Promise<FileBlameInfo>

    // Get the history for a file, to allow
    // quickly navigate and diffing commits
    getHistory(filePath: string): Promise<FileHistoryInfo>

    // Get conflict regions for a file. This will be used
    // for a 'buffer layer' so that we can render some
    // custom UI for this.
    getConflictRegions(filePath: string): Promise<ConflictRegionInfo>

    // Change the branch
    changeBranch(branchName: string): Promise<void>

    // Get all available branches
    getBranches(): Promise<string>
}

Then, individual plugins could provide implementations of this. For example, a plugin like oni-plugin-git might have this:

export class GitVersionControlProvider implements Oni.Plugin.VersionControlProvider {
    ....
}

oni.vcs.registerProvider(new GitVersionControlProvider())

In addition, we'd want to add a 'contributes' section to the plugin metadata and a relevant activation event, so that we can 'lazy load' these plugins - we wouldn't need to load the VCS plugin until we've opened a workspace.

(I anticipate that the version control provider would listen to buffer events, like save, so it could use those to decide when it should check VCS status).

Even the relatively simple interface above would let us accomplish a pretty significant subset of functionality!

I think it would make sense to bundle the git integration as a first-class citizen, but allow this API to be open for other version control providers, too.