+12
Completed
Log: don't hide graph when filtering
In our company all deployed packages contains the GIT SHA1, so we can know what code level is running. From time to time, we have to check where a specific SHA1 is located in the log. To achieve this, we need two steps :
- fill in the search field with the SHA1, enter
- on the found commit, right click and select the "reveal commit" option
Not very pleasant...
But this is more of a general question : this choice of hiding everything to give only the found commit(s) is too much often not in phase with what we need in our team, so I suppose this is a common problem.
I would suggest one of those solutions :
- if only one commit is found (or we're obviously searching on commit IDs ?), then just jump to this commit in the log, and otherwise keep current implementation (display search results)
- highlight the found commits in the log, and have next / previous buttons
- have a separate search results window (maybe not a real window but a tooltip ?)
BAD, I'M UNSATISFIED
The solution proposed is just a workaround, can't be found easily and I also found no mention of this in the documentation...
I really think changing the search would be a great benefit for the product.
Satisfaction mark by Pierre Goiffon 6 years ago
Customer support service by UserEcho
You may try typing the ID directly into the focused Commits view (or use Ctrl+V to paste it). This will trigger the speed-search.
Good solution for now, thanks ! I've never heard of this functionnality sadly, although I'm constantly watching changelogs and the "what's new" page... And it seems impossible to find for a new user...
And frankly, I still have the same request, cause almost everytime I want to see where are the commits in the log... It think the second proposal would be ideal ?
I'd love to see the branches when I'm filtering - this would work nicely with the proposed highlighting.
I think that we better keep current 'filtering' and add 'searching' with next/previous sub-commands.
We also run into this regularly, but in our case it was more frustrating because we didn't think to use "Reveal commit". We did:
1. Type into filter box and find the correct commit
2. Select the relevant commit
3. Hit "x" on the filter.
This seemed like it should work, because we had these expectations:
1. The selection in the "Commits" window would be retained
2. The "Commits" window would be scrolled to keep (at least a portion of) the selection in view
#1 seems like a fairly fundamental user expectation, and it was quite surprising (and frustrating) for it to be violated. We didn't think to use Pierre's "reveal commit" workaround, because it seemed to be already revealed. So we resorted to "remember the commit date and perform a manual search after clearing the filter".
Obviously, the speed-search is the most streamlined UX, but it's quite undiscoverable. Improving that would be fantastic; but I think it would also be good to implement #1 despite the fact that revealing commits is a potentially-expensive operation. (Probably the filtered view would also have to avoid automatically selecting the first commit)
As already answered by Thomas Singer, you can focus the Git Commits view and directly type (or paste with CTRL+V) what you're looking for (SHA1, description, author) and you'll see a "Search For:" input appear at the top left corner. Then you can hit F3 or SHIFT+F3 to go to the next or previous match
+1 for highlighting matches, makes several related commits (e.g. issue number) to be more easily distinguishable in the log
(similar to Notepad++ :
SmartGit 18.1 preview keeps the graph visible when filtering.