@colin Yes, but try it when you've first filtered your log by doing a search. Say your team puts a JIRA ticket at the start of each commit, to identify what feature it belongs to. Now say your feature's commits are interspersed with other commits. So you search the log by that ticket, pulling up just those commits. You want to select the first and last commit to see a diff of the files, and then drill into each file to see what's actually changed. But you can't because in actuality SmartGit (or Git itself?) treats it as if you've selected the range of commits in the actual full git log.

As a solution, SmartGit could make a temporary new branch, cherrypick each of the commits from the search results into it, then provide its file diff-ing based on that. It'd save me the trouble of having to do that myself. And it's a very common problem for teams that don't mandate that all feature/task/whatever work be done on their own branch, regardless of how small.

Sounds good to me to merge this idea into topic 201. My only goal is to be able to review someone's changes when their multiple checkins are interspersed among other checkins, provided they used a unique word (such as a feature ID or JIRA ticket#) for searching upon in each of their checkin comments.

I don't believe that's necessarily asking for the same thing. I'm asking for file and contents diff'ing across a range defined by a single start commit to a single end commit shown in a search results of the log, so that it discludes all changes of commits between the start and end that are not in the search results. It's a common pattern for reviewing when the author didn't use a feature branch.