When I'm looking if a property exists to configure a feature, it's a long list to scroll through for key words.  Filtering the list would be very helpful.

Setting the column configuration for the Journal pane should not affect the Log pane, and vice-versa, each should have their own settings.

The desired set of columns and how the values in that column are displayed (e.g. compact vs full name) are different for the Journal pane than for the Commit pane.

For example:

My Journal pane is narrow, sharing the window with with 2 other panes that I like to see next to it, so visible space is limited. On the Journal, the most important column is the message, but I'd also like to see the date and the author (but showing the compact author is fine) in order to give more space for the message. If I can't horizontally scroll, I may decide I don't want the date displayed so I can see more of the message.

My Log pane is much wider with only one pane next to it horizontally because I want to see much more. The message is still the most important column, but I also want to see the full author name and the date.

Currently two changes views are available:

- HEAD vs Index

- Index vs Working Tree

I propose to add the third one: "HEAD vs Working Tree", which would ignore Index and show diff between the current state of the working directory and the latest commit.

1. Allow "word-wrap" feature in this tab so that we don't have to scroll horizontally.  It looks like this tab is implemented as a list or something, so hopefully the contents of the list can be word-wrapped.

2. Allow separate font size for [Output], just like in Visual Studio.  [Output] tend to be verbose, so it would be nice to see more of the data in a glance.

Blame is great, but can be very slow.

I would like to recommend making blame into a submenu, or have blame open a selection dialog where the "from date" or "up to x months/years back.

This would prevent blame logs for larger files (or with massive histories) from taking several minutes to open, when all you really want to check might be who made a certain change in the last 6 months.

It would be convenient to make a shortcut to the Reveal command.

I suggest Ctrl+Click.

This combination is used in such products as Visual Studio, Microsoft Word, Microsoft Outlook, notepad++, so it will be familiar for many users.

Not each project impose the same limits on how the commit message must be crafted.

Since the limits may also be "soft" limits, it would be great if one could see the current cursor position in some status bar (like :set ruler in vim, or any other text editor shows by default).

SmartGit's current memory usage is fairly excessive. In our 257,000 file repo, here's what I'm seeing when launching SmartGit64.exe without smartgit.vmoptions file:

• 380 MB: sitting idle at the "Welcome to SmartGit!" dialog before selecting a repo
• 816 MB: sitting idle after selecting repo and letting initial refresh complete
• 860 MB: after opening a log window and then closing it
• 952 MB: after opening a second repo in the same SmartGit instance, opening a log window and closing it
• 952 MB: after closing the second repo and using Debug->Run GC a few times
• At this point the "SmartGit is close to the configured memory limit" dialog pops up

In the past I've used the -Xmx2300m vm option to avoid the memory limit warning, but then SmartGit uses up closer to 2GB of RAM in normal usage (and "Run GC" does nothing to lower it).

This is a lot of memory to give up just to use source control, especially on the VMs we use for development. Would it be possible to do a pass to see if there's any unnecessarily large data structures or redundant data that could be de-duplicated?

I'm not sure what happens during refreshing, other than it counting up the files to ignore. But it could probably run in parallel for many files, right? That would help with large repos like Unreal Engine.

Recently, I have seen a few broken repositories, both on my computer and my team members' computers. I believe this is connected to SSD's, where failing to write cache (due to blue screen or power failure) will often turn a file into a handful of zeroes.

Repairing a repository is usually simple, git fsck will tell SHAs for objects that are corrupted, then one needs to find the same object on remote, or team member, or backup, or a copy of repository, and copy it to corrupted repository.

In practice, repairing by hand is more complicated:

1) Many people simply don't know how to repair a repository

2) Repairing by hand becomes more difficult when object is packed on healthy repository.

I suggest that a feature is added to SmartGit, which will search all known copies of repository for a healthy copy of corrupted object, and repair it.