Re: gitk highlight feature

[Linus Torvalds <torvalds@osdl.org>]

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