How do you open a given repository in the Git Tab?


I’ve looked through GitRepository api docs and there doesn’t seem to be a way to open the repository in the Git tab directly?

Is it possible to choose where the Git tab opens (programatically)?


The Git tab corresponds to the repo containing the file associated with the active TextEditor. If you want to change repos, just click over to a file in the one you want to mess with.


Well that’s not entirely true… For example if I have a folder full of GitRepositories, the Git tab doesn’t work for any of the sub repositories. It literally only works if the active project has a .git file. So I was wondering if there is a method in the API which opens the git tab for a given github repository. If so I could make some wrapper code for the project’s treeview, so I could at least work in folders with sub-git repositories


Atom’s git integration only works for directories you have added as project folders. It doesn’t work for their children. You will have to add all of the git repos you want to access as project folders.


I see, somewhat odd because Atom’s Git API can be used directly regardless of the current project, e.g.

function getRepo(path){
  var directory = atom.project.getDirectoryForProjectPath(path)
  var provider = atom.project.repositoryProviders[0]
  return provider.repositoryForDirectorySync(directory)

So I guess I’d have to implement my own git tab then… Well, good to know.


The API is just a bunch of functions that can be applied anywhere. You don’t even need the API; Atom comes with a copy of git, so you can go raw Node and call that executable with child_process on any folder on your computer. That’s easy to do, it just takes time and then you have to know where git is on three different platforms, plus you have to know what you’re looking for on the output side. What the API does is take all of that work and hide it behind simple methods that take arguments and return data. The JavaScript methods available to you don’t necessarily have bearing on how Atom behaves (in fact, they frequently don’t, which is part of the design philosophy of Atom wherein users are empowered to make the editor they want to use; the API supplies tools with few opinions about how they should be used). Atom’s git integration consists of the core github package, which controls the behavior of the Git and GitHub tabs and the file tracker. Implementing new behavior is as easy as disabling the core package and writing new code to take its place.


So do you mean to say that the github package is not the provider of the API? (I.E. I expected disabling the github package to also un-expose the git api… Is this not the case?) And yes, I had indeed anticipated it’d be a fair amount of work to re-write the github package. But that doesn’t mean it wouldn’t be worthwhile.


Any function listed in the API reference is part of Atom’s core, not a package.

Look at it this way: the API is a collection of possibilities, but makes very few decisions about which possibilities are actually pursued in order to arrive at the functional behavior of Atom. The developers have made some decisions about what they want to see, and complex behaviors informed by their preferences have been written into core packages such as tree-view, tabs, find-and-replace, and github. Any package that uses the functions exposed in the API will work in any appropriate version of Atom, even if those core packages are disabled. If you do want to use an API exposed by a package, such as tree-view, you have to tell Atom that you’re doing that. If you don’t explicitly do that, you should not make any assumptions about which packages the user has installed or enabled, even core packages.

And yes, I had indeed anticipated it’d be a fair amount of work to re-write the github package. But that doesn’t mean it wouldn’t be worthwhile.

I have not done the reading to find out if this is true, but there’s a chance that the github code could be tweaked in a couple of places to allow for focusing on child folders. If the scope of the changes you would need to make are less than a couple hundred lines of code, you might find it more productive to fork the core package and keep your changes separate enough that you can incorporate non-conflicting improvements to the core package’s code. Even if it turns out to be the case that you want to write your own package, you might find it edifying to read the core package enough to understand how to change it anyway, because that will give you a better understanding of what a package can do (and this one is a good example; it implements multiple UI elements, handles input and output from external binaries, and has both passive and active features).

I don’t have the time or motivation to give you the final answer, but I love helping people solve problems, so if you have any questions about how Atom works or need someone to bounce ideas or code off of, I and some other very helpful people will be around. :slight_smile: