Your comments
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?)
This would be enormously helpful to me, and to many other remote workers. The central office has the powerful server, but I'm quite a few milliseconds of latency away. I've tried file sharing, but it's super-duper-doggy-slow. Having (most of) the processing done on the remote machine would really speed things up.
You use the color red all over the place to indicate that "There've been changes" (e.g. in the "Staged" indicator, in the "Modified" indicator, and in the whole file list when there are changed files but they've all been hidden by the various display flags). That's a nice consistency which I wouldn't want to lose.
How about this, with a slightly stronger circle around the "Changes Staged" indicator?
I like that the current system uses the same color for all of the "Something Changed" indicators; I wouldn't want to change that. I also happen to like the gentle red. (But, I'm no visual designer, and as you say it's all subjective...)
Adding a stronger outline to the "Staged" circle, or pulling the "Staged" circle a couple of pixels to the right, would really help.
Understood. I prefer the new behavior, so I won't revert. (Thanks.)
Customer support service by UserEcho
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.