Suggestion for keybindings in README

[nh2]

I liked your explanation in https://github.com/timbrel/GitSavvy/releases/tag/2.23.0 suggesting gs_inline_diff and gs_stage_hunk as key entry points into the GitSavvy workflow.

I propose:

• to add those explanations to the README, not only to that one's release notes
• to not suggest ctrl+shift+[ as keybinding, because that's a default Sublime keybinding already (for folding/unfolding code sections)
  • to suggest ctrl+alt+g (g for git) instead. Then you have for example this, which is easy to remember and unbound in default sublime:

    // GitSavvy bindings
    { "keys": ["ctrl+alt+g"], "command": "gs_inline_diff" },
    { "keys": ["ctrl+alt+s"], "command": "gs_stage_hunk" },

[kaste]

Yes, we totally need some explanation in the README or a first-starter ".md" file somewhere. Esp. everything gets really faster if users add some main entry points to their key bindings.

That being said, v2.23.0 also introduced many changes to gs_inline_diff, before it wasn't a good starting point at all.

Traditionally, the main entry point was probably "ctrl+shift+s" for the "git: Status", and then you could open diffs, stage directly, and enter the commit phase. Since this year, the "Repo History" has improved so that a "ctrl+shift+g" to open that view is also very useful.

Funny enough, I used ctrl+shift+[ in the release notes because I thought that reads so obscure that users will actually not just copy paste but think and adjust to their liking. Also I'm working on actually folding the views based on the diffs.

Currently, since Sublime added some git workflow, I use and then probably propose binding

• ctrl+, and ctrl+. to go to the prev/next hunk (using the new gs_[next|prev]_hunk in the normal views, and other commands if in a special view.)
• ctrl+shift+, for the inline diff
• ctrl+shift+. for the normal diff
• plus ctrl+shift+s as mentioned above.

Proposing just the inline diff is not yet enough because the inline diff is too limited. 1. It can only display changes from one file (there is no way to switch between files) 2. You never get an overview of the changes over a long distance because it focuses more on the good readable context of a change. (Here I have a fold command in the making which basically folds (out) context lines.) 3. It completely just doesn't work for files with merge conflicts, or generally if the diff is based on a "combined" diff with multiple parents.

The normal diff on the other side is visually a bit noisy (on the other hand it just displays the standard git diff output users a familiar to read.) And it doesn't scroll very good. (T.i. switching from the editing buffer to the normal diff is not as nice as switching to the inline diff.) It can show multiple files and merge conflicts though.

TLDR; I thought I still need more code before I get to an easier and faster workflow. 🤷‍♀️