Git repositories may be contained in a .git directory or a .git file
in the workdir hierarchy, but Atom only recognizes the directory format.
Teach Atom to recognize the filesystem-agnostic Git symbolic link
used by default in many situations including, for example, submodules.
The .git file contains a relative or absolute path to the location of
the real git-dir, preceded by the 8-byte string "gitdir: ".
Here's a console log showing the normal creation of such a symbolic link.
/tmp $ git init --separate-git-dir foo.git bar
Initialized empty Git repository in /tmp/foo.git/
/tmp $ ls
/tmp $ bar foo.git
/tmp $ ls -la bar
drwxr-xr-x 2 hordp hordp 4096 Sep 18 15:54 .
drwxr-xr-x 4 hordp hordp 4096 Sep 18 15:54 ..
-rw-r--r-- 1 hordp hordp 25 Sep 18 15:54 .git
/tmp $ ls foo.git
branches config description HEAD hooks info objects refs
/tmp $ cat bar/.git
gitdir: /tmp/foo.git
Fixes#8876
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()`.
