Regexps are a very good idea - it lets users specify what the path separator is. For us we use release branches in the <year>.<quarter> format, so none of the `/`, `-` or `_` separators work.

Yes, that's what I mentioned in my second comment, the file is selected so it's better than I initially thought, but the selection moves around and it's a flat list of files, so it's cumbersome.

I don't have it set to show unchanged files, but if a file is modified every few weeks and I want to see changes across a couple of months, I'm going to have a very long list of all the other files that have been modified in the meantime. 99% of these files are irrelevant to me.

It's not that it's broken, it's that it could be better :D

I had not noticed the file highlight, maybe it's too subtle? :D Even though, with 35k files in the repository, the list changes and the selection moves around, it's kinda confusing. Note that in our case, a given user only looks at maybe a dozen files out of all the ones in the repository.

No, this is about comparing a locally modified (but uncomitted) file with what's on another branch (typically fetched but not merged remote branches).

Agreed, this is very helpful when your local branch is behind the upstream and other developers have added commits on the same file. You're not ready to rebase yet, but you want to understand how the other changes impact yours. It's very easy to do on the command line.

The Show Changes window could be improved so that you can select the reference (on the left or right pane).

We use Git notes to keep track of the CVS revisions each commit has been created from. This would be very helpful to us, since our developers need to understand in which build their changes are going (we still live in a dual CVS-Git world).