jskinner

My pleasure, and thanks for the kind words!

There are only minor changes in this build: a few bug fixes, plus notarization support, which is required for macOS 10.15.

We've got some pretty exciting changes coming up quite soon, but this isn't it.

We do defer to Git for all write operations, but for reading, we do it ourselves partly for efficiency, and partly to get the right data.

In terms of getting the right data, one example is that we need to know the full set of non-ignored sub-directories in the working directory, so we can watch them for changes. It's easy enough to generate this ourselves as we calculate the status output, but I don't believe that git will emit it.

In terms of performance, we rely on being able to read objects efficiently. For example, to show a commit, we can't just use the output of "git diff", as we need the full file contents to be able to calculate syntax highlighting correctly. You could go a long way with "git cat-file --batch", but there are plenty of contexts where you can't practically batch requests, and process creation costs + the lack of caching across requests (which can be quite significantly due to the delta encoding of objects) would be quite significant.

It's not configurable, but you can click on the "Working Directory" head to collapse all the files there, which will make seeing the Staged changes easier

Git hooks will be run, as all mutating actions go through git itself, however pre-commit hooks may not work as you expect with this setup. When you commit via Sublime Merge, it's doing a git commit -m "...", which works differently with git hooks than a plain git commit.

We use the system Git by default on Mac if it's installed, but it sounds like that's not working for you. If you set your git_binary preference to "bundled", we'll use the one that comes with Sublime Merge instead.

It's not exposed via the command line right now

Thanks for your support!

We have hidpi support on every platform.

If your dpi scale isn't being detected correctly on Linux, you can set it explicitly via the dpi_scale setting (there are instructions elsewhere in this thread)

The billing period isn't changed, instead a pro-rated amount is changed. For example, if you add a seat half way through the billing period, you'll be changed half the normal amount for it. Reducing seats will result in a pro-rated credit on your next billing cycle.

Menus and dialogs (open, save, error, etc) :)

There isn't right now, but there will be a new build out soon that will work with this.

Thanks for the kind words!