On Wed, 3 May 2006, Paul Mackerras wrote: > > Linus Torvalds writes: > > > The obvious way to do it would be to just have two buttons per view: one > > exclusive one (for the main view - only one selected at a time), and the > > other one for the "highlight" one where you could allow multiple views to > > be selected for highlighting. > > That's hard to do in a menu, but I could do it in a separate pane. > Or, I could draw a series of tabs between the menu bar and the > graph/headline/author/date panes. Each tab would have the view name, > a radiobutton to select it for highlighting, and a close button. Actually, having used this thing (and thought about) some more, I'm afraid that I'll have to just admit that my whole "highlight" thing was misdesigned. One is just an interface issue, and I think that it would be fixed by just removing the highlight entry from the "view" menu, and making it a menu of its own. That, I think, would fix the user interface to be more obvious and intuitive. But the real thing I found is that when I decided I wanted to highlight, I didn't actually want to highlight by "git-rev-list" at all. At least not most of the time. So far, what I've wanted to highlight by is: - "does it touch this file/directory/pathspec" This is _close_ to "git-rev-list", and you can (and do) actually implement it as that, but it's stupid to do it that way. You just spend extra time. It's literally much better to do cat commit-list | git-diff-tree -s --stdin -- <pathspec> which is a hell of a lot more efficient, since you already have the commit-list you're interested in (and, in fact, this allows you to do things efficiently only for the current _visible_ commits, if you want to, which might be an important optimization for large views). - "Does the author/committer match xyz*" I ended up using the "search" button for this, and it worked, but the highlight feature would just have done it much better. Especially if there was a way to do "go to next highlight", instead of just "go to next commit" Again, this is actually most easily done by just using the commit-list you already _have_. Not with adding a new argument to "git-rev-list" and trying to filter two views. Also, again, this can actually be done for just the "visible" ones, not the whole view. - "highlight the commits [not] reachable from the selected commit" Now, this literally is "git-rev-list", but it's a variation on it: you don't want a new view, you really want the _old_ view (exact same git-rev-list arguments), but you add "^commit" to the list of revisions. And then you (conditionally) invert the highlighting if you wanted "reachable" rather than "not reachable". And the current "create a new view, and overlay that on the old one" approach really isn't that good. My mistake, it was me who suggested it. What do you think? Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html