Git Plugin design

#Overview This page is to consider design and implementation details for a Git plugin for LightTable. This is one of the most requested plugins so far, and since Git is an essential part of the workflow for many of us, let's make sure we get this right!

I (mdhaney) have done a fair amount of investigation and written a bit of preliminary code for this, but feedback and collaboration is welcomed and encouraged. I'll start by listing my thoughts on the topic, and we can edit this page as the design progresses.

#Approach It probably makes sense to use one of the npm packages available for git. Most of these are just wrappers around the git commandline. There are a few out there to choose from, so if anyone has experience with and can recommend one package over another, let's hear it.

I've broken the project into 3 increasing levels of functionality. Let's flesh out this list first and make sure we get our priorities straight. In the meantime, I'll cleanup the code I have written and get a repo up, then we can start adding these to an issue tracker.

##Core integration/synchronization

• LightTable needs to be aware of the existence of a Git repository when folders are added to the workspace (I've done some preliminary work here). We shouldn't assume a 1-1 correlation between root folders in LT and git roots/repos. For example, 2 different folders might be added separately to LT that are part of a larger single git repo. The approach I have taken so far is to create an object for each unique git repo and then associate root folders with the repo they belong to.
• LT should know the git status of each file (modified, created, deleted, ignored). We probably want some indication in the UI of this, but nothing obnoxious like icons IMO. Maybe something like, ignored files are slightly darker, modified files are italicized, new files bolded, removed files (dunno?). Also, do we want the visual indicators to show up just in the workspace sidebar, or also in the navigator (I'm leaning toward the latter).
• Branching - initially, we should at least be aware of branch switches, even if we don't allow branching within LT right off the bat. We need to sanely handle: disposing/updating editor tabs for files that changed, updating the workspace and navigator sidebars, and possibly killing clients (project.clj changes/goes-away - kill the nrepl client? Still a little fuzzy on all the implications here).
• Basic commit functionality, i.e. hit a hotkey, tab pops up listing all changes, enter a message, hit commit and we add everything to the index and commit.

##More thorough integration

• Better control over the index, so files can be staged/unstaged before commits
• Revert files
• Branch within LT
• Push/pull

##Sugar coating

• Browse history
• Github integration (i.e. clone a project and add it to the workspace right within LT)
• Gists!
• Some really cool graphical diff/history viewers and other eye candy?