Presumably any search results returned by Control-P would be ordered by relevance; in the case of commits by name, the most relevant in my opinion would be the most recent commits. My goal with this would be to have  super-fast way to see the most recent N commits by commiter name, or by message contents (as opposed to the current method of "open log, select the right branches, click in the filter window, type the search contents".

Not that I am aware of, thanks.

I think the problem is user experience. Currently, to export settings, you have to know to:

1. Know that, to find the right settings folder, you must:
   1. choose "about smargit" from the Help menu
   2. click on the "information" tab
   3. click on the folder icon next to "Settings path"
   4. figure out which of the potentially-many version-specific folders to enter (are you running Smartgit 20.1, 20.2, ...etc)
2.  Figure out which files should be copied, and which shouldn't. There are currently 26 files and 6 folders in my "settings path" --- which are needed when migrating to a new machine? If I want to create a "clean" but pre-configured set of settings to distribute within my organization, what's the minimal set of files necessary? Which are safe to migrate across versions?

People use SmartGit to avoid needing to think quite as much about the complexities of their source control system. It would be nice if they didn't have to think so much about settings import/export, and could just click an "import settings" and "export settings" button in the UI.

This would be quite helpful for me. Our commit graph has lots of merges, so when filtering the graph by, say, author name, half the commits shown are just merges and not actual matches. Having a way to visually identify the actual matches would make it much easier to understand filtered graphs.

Thomas,

I really like this new feature, but there's one minor annoyance. When the feature is disabled, and you are interactively staging changes with the "changes" window open, the Changes window retains the selected file and the selected file position. However, when this feature is enabled, as soon as you stage the first change, the changes window empties because the file is de-selected when it's moved from one pane to the other as a result of the first change being added to the index. This is pretty jarring when you're moving through a big file with lots of changes, trying to interactively stage bits and pieces.

Is it possible to preserve the selected file and position? My thinking is that the working tree version of the file would remain selected until it's fully staged, at which point the selection would switch to the Index version of the file.

I see. That's confusing, but I guess that's what you get if you muck around with low level properties ;)

Maybe just make a note in the description of the property?

Thomas,

The vertical split works great when I enable that option. Thank you!

One note: that property required a restart before it took effect. That might be worth noting in the dialog.

I really appreciate Syntevo working to add this functionality. I hate to, as they say, "look a gift horse in the mouth", but is there any way to configure it to

1) show them in separate windows so we can view them side-by-side vertically instead of the current horizontal split? I have lots of horizontal monitor space but vertical space is at a premium and I prefer to reserve it for the changes pane.

or, at the very least,

2) control whether the index is shown in the top pane versus bottom pane?

Thank you!

From what I can tell, you cannot currently quickly search for the following using Ctrl-P or Ctrl-Shift-P:

• Preferences (Edit > Preferences options)
• Commits by commit message contents (i.e. quickly search for commits containing a specific string)
• Commits by committer name

Having a quick key combo to search commits without needing to open the log first would be a big time saver. That's the thing I'm most looking forward to.

Thanks for looking into this, Marc. 

I just tried it out in the latest build (18.2 preview 6 #13110, installed: #13077) and 

1. I don't see any difference in behavior when log.forceLocalActionsOnEntireRepository is true versus false. 
2. I find it confusing that this option (I think?) affects both the "commit" button on the toolbar and the right-click > commit behavior. 
3. Neither option allows you to commit a single specific staged file when other files are staged.

Here's the behavior I would like to see is that the toolbar icon ignores selection completely and operates on all files, while the right-click menu item operates solely on selected files:

Test A:

1. Set up a repo with 3 locally modified files where none are staged
2. Make sure no files are selected and click the "commit" button on the toolbar
• Expected: all 3 modified files are prepared for commit
3. Select one or more files and click the "commit" button on the toolbar
   • Expected: same as before --> all 3 modified files are prepared for commit
4. Select a single modified file and right click > commit
   • Expected: just that single file is prepared for commit
5. Select 2 of the modified files and right click > commit
   • Expected: only those 2 files are prepared for commit

Test B:

1. Set up a repo with 3 locally modified files, where 2 of the 3 files are staged
2. Make sure no files are selected and click the "commit" button on the toolbar
• Expected: only the 2 staged files are prepared for commit
3. Select one or more files and click the "commit" button on the toolbar
   • Expected: same as before --> only the 2 staged files are prepared for commit
4. Select the single un-staged modified file and right click > commit
   • Expected: just that single file is prepared for commit, the other 2 staged files are ignored
5. Select only 1 of the 2 staged files and right click > commit
• Expected: only that single staged file is prepared for commit, the other staged file and the unstaged modified file are ignored
6. Select both of the 2 staged files and right click > commit
   • Expected: only those two selected files are prepared for commit, the other unstaged modified file is ignored
7. Select the un-staged modified file and 1 of the staged files and right click > commit
   • Expected: only the two selected files are prepared for commit, the other staged file is ignored