The dream would be the latter, and I understand completely.

"Expect" is too strong a word, but I would like SmartGit to be able to work relatively quickly over an ssh connection, perhaps by using a tool of some sort installed on the remote machine.

That will compare the working tree with the merged branch, but not show anything about the target branch. In otherwise, it just shows two file states and their differences. (right?)

The "Conflict Solver" shows three file states: the merged branch, the target branch, and the working tree in the middle. I can see where any change came from, and what's different from either source. Would be very useful.

I get burned by this all the time, because I forget that I'm editing in BBEdit when I open a File Compare window.

BBEdit actually Does The Right Thing™. When you switch to it, it checks all open windows for their disk files having changed. If a file changes, and there are no changes in the window, then it silently updates the window to the file's new content. If the window has unsaved changes, then it offers four choices (from BBEdit 12.6.7):

This is a wonderful thing, and it would be great if SmartGit did something similar (although not all the choices would make sense).

Works for me: thanks.

Well, things are now a bit faster (where "a bit" means "two orders of magnitude". Yowza. ;)

I presume this is an application-level preference; can this be done on a per-repo basis? And, there doesn't seem to be a UI indication that submodules aren't being scanned (I just tweaked a submodule, and the top repo still shows "Unchanged"); could there be? Best case would be some sort of "Unmanaged" indication, with a method to open and see the state of that submodule.

They are indeed registered for everyone. In other words, there's a .gitmodules file in the top repo with the following (partial) contents:

[submodule "buildroot"]
	path = buildroot
	url = ../../ext/buildroot.git
[submodule "linuxptp"]
	path = linuxptp
	url = ../../ext/linuxptp.git
[submodule "linux"]
	path = linux
	url = ../../ext/linux.git
[submodule "u-boot"]
	path = u-boot
	url = ../../ext/u-boot.git
	branch = u-boot-2013.01-15t1-clearfog
<snip>

What is slow is just about everything. And again: this is over a networked drive (with sshfs), so that's part of the problem, but it isn't something I can easily make local, as the build system depends on Linux, and I'm running on a Mac.

Yes. I believe this is true anywhere you can edit the text of a file.

Ah, such is life...

Remote machines always support ssh, but almost never file sharing. Even if sshfs is used, the latency to the server makes file sharing far too slow for the disk-access-heavy actions that git and SmartGit use. This means that we must go back to caveman days and use command-line git to manipulate files on the remote machine.

Yes, I could use a local clone, but the remote machine is a monster Linux compile engine with the cross-platform development tools I need. It's also proximal to the hardware I'm developing for. I'd have to commit and check out every time I wanted to compile. Note also that I'm compiling the Linux kernel, which can only be done on a case-sensitive file system, and macOS and Windows are case-insensitive. (Separate gripe: tens of thousands of source files, and somehow it's important to have those twelve pairs of files whose names differ only by case? Grrrrr...)

I don't know SmartGit's internals, but it seems to do a lot of its intensive file access by directly calling the git tool. The obvious thought is to have SmartGit reach across the network and call git on the remote machine, thus drastically cutting back on the network traffic required. This ignores when SmartGit directly accesses the file system, but perhaps that's well-capsulated and so could be easily redirected across ssh.

(I understand about the low priority, but we can dream, can't we?)