This gives GitRepository the chance to clear its path cache before the callback
is invoked. Otherwise reads from the cached status state within the callback
would be wrong.
GitRepository class documentation references deprecated method
Project::getRepo. This resolves that by instead using the replacement
Project::getRepositories.
Although, it seems as if that will be removed in v2.0, so perhaps we should
update this to instead using the async Project::getDirectories method, coupled
with Project::repositoryForDirectory?
/cc @atom/feedback
Fixes#8971
I tested this by creating a dummy implementation of an `HgRepositoryProvider`
(with the optional `createRepositorySync()` method implemented) and an `HgRepository`
in an Atom package with the following stanza in the `package.json`:
```
"providedServices": {
"atom.repository-provider": {
"versions": {
"0.1.0": "createHgRepositoryProvider"
}
}
},
```
I opened a path with an Hg repository from the command line using Atom.
I verified that `atom.project.repositoryProviders` contains both a
`GitRepositoryProvider` and an `HgRepositoryProvider`.
I also verified that running the following printed out an `HgRepository`:
```
var Directory = require('pathwatcher').Directory;
atom.project.repositoryForDirectory(
new Directory(atom.project.getPath(), /* symlink */ false)).then(
function(repo) { console.log('repo: %o', repo); });
```
One thing that stands out to me about the current API for the
atom.repository-provider service is that the function used to create
a `RepositoryProvider` does not receive any arguments. If the creation
of the `GitRepositoryProvider` were done via the service, this would
be a problem because it needs a reference to `atom.project`, which is
not defined when it is created. (We work around this because it is
created in `Project`'s constructor, so it can pass `this` to
`new GitRepositoryProvider()`.)
We would have to create a `RepositoryProviderFactory` or something if
we wanted to specify arguments when creating a `RepositoryProvider`,
in general. Maybe that's too crazy / not an issue, in practice.
Though note that `GitRepository` cannot access `atom.project` lazily
because it uses it in its constructor to do the following:
```
if @project?
@subscriptions.add @project.eachBuffer (buffer) => @subscribeToBuffer(buffer)
```
So long as we can guarantee that `atom.project` is defined before the
other providers are initialized, I think we should be OK.
Follow-up work:
* Replace the use of `RepositoryProvider.createRepositorySync()` with
`RepositoryProvider.repositoryForDirectory()` in `Project.setPaths()`.
* Replace all uses of `Project.getRepositories()` with
`Project.repositoryForDirectory()` in packages that are bundled with Atom
by default.
* Implement `Directory.exists()` and/or `Directory.existsSync()` and update
`git-repositor-provider.coffee`, as appropriate.
* Eliminate `GitRepositoryProvider.repositoryForDirectory()`'s use of
synchronous methods.
* Somewhat orthogonal to this diff, but the following fields need to be
removed from `Project` because they enforce the idea of a single root:
`path`, `rootDirectory`, and `repo`. This has implications around the
existing use of `@rootDirectory?.off()` and `@destroyRepo()`.
We were calling @unsubscribe with the TextBuffer, which previously
unsubscribed from that object. The problem is that we were no longer
subscribing to that object directly, but only adding subscriptions to
that object. This caused us to never unsubscribe from buffers.
