[smashwilson]

When gitTabActive was "false" and the toggle method was invoked, the state was being toggle to "true" correctly, but the DockItem was not being toggled correctly in the workspace. As a result, it took two invocations of github:toggle-git-tab to show the Git tab if the dock it was in was not visible.

Probably addresses #891.

• Clarify state transitions in TabTracker.toggle() with and without legacy panels active. With legacy panels, the gitTabActive component state dictates the visibility of the panel completely, so toggling should only flip the state; with the dock API, gitTabActive controls whether or not the tab is rendered, not visible, so .toggle() may need to reveal the dock.
• Bring the RootController tests up to date. There are a few still failing because isGitPaneDisplayed doesn't account for the docks API.
• For new projects when the docks API is available, default the Git and GitHub tabs to rendered but not activated. Meaning, if you open Atom on a new project, the right dock is hidden, but if you open it yourself the Git and GitHub tabs are present by default.

[smashwilson]

For new projects when the docks API is available, default the Git and GitHub tabs to rendered but not activated. Meaning, if you open Atom on a new project, the right dock is hidden, but if you open it yourself the Git and GitHub tabs are present by default.

☝️ This is the bit that I'm least certain about from a "what do we actually want to happen" perspective. @BinaryMuse, @kuychaco, @simurai, any thoughts on this?

[simurai]

For new projects when the docks API is available, default the Git and GitHub tabs to rendered but not activated. Meaning, if you open Atom on a new project, the right dock is hidden, but if you open it yourself the Git and GitHub tabs are present by default.

Sounds good to me. 👌 Since there is nothing to stage/commit when opening a new project, I think it's preferable to have it closed. I guess it depends how wide your window is, but I'm a fan of starting out minimal because it's hard to know what a user intends to do next.

[smashwilson]

Here's the matrix of cases that I'm testing:

• atom.config('github.useLegacyPanels', true)
  • atom.config('welcome.showOnStartup', true)
    • ~/.atom/github.cson does not exist
      • Panel is not visible
    • ~/.atom/github.cson exists
      • Panel is not visible
  • atom.config('welcome.showOnStartup', false)
    • ~/.atom/github.cson does not exist
      • Panel is visible
    • ~/.atom/github.cson exists
      • Panel is not visible
• atom.config('github.useLegacyPanels', false)
  • atom.config('welcome.showOnStartup', true)
    • ~/.atom/github.cson does not exist
      • Dock is not visible
      • Panes are present within dock when expanded manually
    • ~/.atom/github.cson exists
      • Dock is not visible
      • Panes are present within dock when expanded manually
  • atom.config('welcome.showOnStartup', false)
    • ~/.atom/github.cson does not exist
      • Dock is visible with panes
    • ~/.atom/github.cson exists
      • Dock is not visible
      • Panes are present within dock when expanded manually

[smashwilson]

@ungb, this should fix the "need to click twice on the 'open git' button" issue that you found testing out #875. Once this is ✅ I'll merge, publish, update in atom/atom and cherry-pick it on to 1.18-releases and we can re-verify 😅 . Hopefully the test-case enumeration up above (and a lot of atom-beta --clear-window-state) might be helpful for making sure that everything is behaving as we expect it to!