Also, the find/search bar only searches commit messages, not commit ids. There should be a way to jump to specific ids.

Nicolas: Agreed, but that should be a separate operation somehow.  gitg shouldn’t assume that I want to jump to a branch named “stuff” when I actually want to search for all commits mentioning “stuff”.  (gitk uses two different text boxes for these, for example.)

Note that both statements are incorrect. gitg will go to the first match of a search, but then you can use the arrow keys to go the next match etc. Also, there is a menu when you click on the search icon that allows you to match also a hash for example.

That said, I really don't like the current search interface. It's functionality is not discoverable, it's slow and unintuitive to use. I will leave this bug open to track progress on the search stuff.

Ideally what I would like is to filter items based on the search criteria. However, the current implementation is not efficient and would have very bad performance on moderately large repositories. Help would be greatly appreciated.

Jesse, you are right. The search box allows the arrows for next search, and clicking the icon can choose what kind of search (subject, author, date, hash).

I guess it's a usability issue problem then: after two months of usage I was still unaware of that feature!

But if you want to change how the search is performed, then this can be ignored.

I'm not sure I understand how you see the new search engine with the filter thing. What do you have in mind?

What I would like to see is instead of scrolling the list to a match, to filter out all non matching items from the list. This will make it much easier to see which items match, and if you can find the one you need. Then there should be a shortcut to quickly clear the search so that you can also then investigate the history of that item properly.

For the search engine itself, I am not really sure what would be a good solution. It's currently fast for hashes, but anything else will simply do utf8 strstr on every item. This currently works reasonably because it will stop each time it finds the next item. Filtering this way however will lead to very bad performance. Ideally some kind of index (or suffix tree, or something similar) should be built from the items so searching is fast. I'm not sure how fast building the index would be, and if it would be possible to store a cache on disk, etc.

Currently, search is not implemented for history view (where commits are shown). 

Changing version to 'git head'and marking bug as 'NEW'.

Urgh. Just found out the hard way that this feature is gone in the new series. This is a huge regression for me as it was one of the killer features I used in gitg even in its previous imperfect state.

As for the backend... silly question: why not just search on the gtk model powering the listview widget? It can store data and filter the widget pretty easily with that, with good performance if I recall correctly.

Retitling this bug report for clarity, since it seems like the feature was actually really gone (not just that I couldn't find it, apparently).

So, I just pushed a fix which enables again searching in the history. Note that this still doesn't filter the view, just searches in it. This is more or less the default tree view behavior, and seems to work fine for now. I'm undecided if we still want to go the filtering way.

Jesse: thanks for this fix.  It's nice to be able to search commit messages, but unfortunately the search still won't find a commit by hash.  That's an essential feature in my opinion.

I personally would prefer a traditional search (find, find next) rather than a filter here.  I often want to see a search result in the tree along with its surrounding context (i.e. the commits that came before and after it).  It seems like a filter doesn't work well for that use case.

Currently a search 'foo' matches only commits whose messages actually begin with the word 'foo', but not a commit with a message such as 'upgraded the foo'.  This is quite limiting.  I think a search should match any word visible in the tree view.

Adam: yes, search is currently really basic (just the standard tree view column based search). Improving it is definitely planned. I actually thought it would already do partial searches (not just prefix), but that's apparently not true. In any case, I'll add this functionality (and searching hashes, refs) soon.

commit 5651fc9483ab920bc2ecac98cccc8a75ff579ee3
Author: Jesse van den Kieboom <jessevdk@gmail.com>
Date:   Mon Jan 5 21:09:03 2015 +0100

    Improve search
    
    Searching now matches partially (not only prefixes) and
    will match on hashes.

This is a first improvement in the right direction. Note that you'll need libgit2-glib master for this as well.

Jesse: I just built with your latest changes and search is now working much better - thanks so much!

One small point: when I type a hash and it's matched, it would be nice to highlight the matching portion of the hash in the lower part of the window.

I'm not sure it's worth it in the case of hashes (although it's not that difficult to implement), since hashes are always matched as a prefix.

Highlighting the matching portion of a hash would make it visually clearer why a particular commit was matched, so I'm still for it if it's easy.  Not a huge deal though.

My drive-by observation is that filtering the list would be a better behavior than in-place find with a pager. Granted we have the ability to clear the search without losing the selected commit for possibly getting more context.

I see that the commit above was included in 3.15 release.
In fact I can search by commit hash on version 3.18.

I noticed that copying hashes from firefox and pasting them into gitg or gitk often doesn't work. While it works if I first paste on, say, gedit and then copy again from there into gitg/gitk.
Some html formatting is getting in the way, I guess.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gitg/issues/5.