Log: List files of multiselected commits (not just a single range)

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.

@jeff, it's reasonable to extend 201 topic for content diffs as well (I guess the author even assumes this implicitly when clicking on a file). To bundle votes, it makes sense to join both issues, but it's up to ...

This already happens...

If you select Commit B and Commit E it will list all the files That have changed between the two. EG, "the diff".. between the two commits.. If you want to also include B's changes too, you would need to select Commit A and Commit E.

What you cannot do is Select Commit B, D, E and G... That is not how Git Diff works. (Which is what the log is based on).

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