Your comments

Clearly there shouldn't be a new, intermediate dialog whenever you choose Blame or Investigate.

So, two options:

  • Have SmartGit respect the presence of a ".git-blame-ignore-revs" file at the top level (perhaps enabled by a config value)
  • Have an "Ignore this revision" context menu choice that, when chosen, recalculates the Blame or Investigate's display without the chosen revision. The next time you open that revision's context menu, there's a checkmark next to the item; choose it again and the ignoring goes away. (Where would this config be stored?)

I'd also like this. If SmartGit could unambiguously detect that a) the file system was case-insensitive, and b) this was causing problems with Git-managed files that only differ by case, then showing a "Beware!" dialog would be very helpful. (Perhaps it could be made optional if it might happen too often in specific circumstances.)

(FYI, here's an email I sent Syntevo a while back, with various performance stats for command-line git.)

I did some testing of git command-line performance, locally and networked. I found that working on shared file systems slows things down by a factor of 100 or more. A simple "git status" could take 80+ seconds (it once took almost five minutes). If that's true with the native git, then I can't really expect SmartGit to be faster.

Times to execute "git status" on the same repo (run repeatedly):

- SMB networked file system over WiFi (100BASE-T speeds): 55 seconds
(but file permissions were messed up)

- SMB networked file system over wired 1000BASE-T: 5 seconds (ditto)

- SSHFS networked file system over WiFi (100BASE-T speeds): 87 seconds
(first time took 297 seconds)

- SSHFS networked file system over wired 1000BASE-T: 17 seconds

- On local system (Recent 6-core Macbook Pro with flash storage): 0.210s

- On local system (Ubuntu w 8-core AMD processor and flash storage):


- Switching from WiFi to wired sped SMB up by a factor of 10, and SSHFS
by a factor of 6

- Switching from SSHFS to SMB sped up by factor of 0.6 to 5

- Running locally can be 1000 times faster.

I'm now using faster wired Ethernet (1000BASE-T), and things are now
tolerable. You might want to share this with the next person who
complains about slow networked functionality.

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).

    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.