On Mon, 29 Jan 2007, Shawn O. Pearce wrote: > > I just implemented the blame --incremental thing in git-gui. That's a real technicolor interface ;) It's prettier, but it highlights an issue I had with the perl-gtk blame viewer too (but there it was overshadowed by all the other aesthetic issues).. One thing I never really enjoyed about the normal "git blame" either, and that the git-gui interface makes even worse, is that it uses a *lot* of real-estate for the blaming. I've got a big screen, and usually run with 100+ character wide terminals, but for git blame, I think the canvas is 120+ characters, and despite that over half of it is just the blame output. That's actually distracting for several reasons: - it may be interesting when the primary interest is the shiny new output from "git blame --incremental", but at least the way I have ever used annotations, I'm not actually *interested* in the annotations until I find the code I'm looking for. In other words, the actual file data is really the *primary* thing. It's the stuff you need to look at first, and it's the thing that ends up making all the rest relevant. The current "git blame" and "git-gui" interfaces just seem to give too much importance to the annotation data itself. Now, in a plain-text pager thign (aka the traditional "git blame"), you don't have much choice. The blame data needs to be there, and you can't hide it, because if you do, there's no way to get at it. But things are different with an interactive graphical environment (or a textual one, for that matter: using some curses interface wouldn't change this argument). You _could_ just make the primary thing be the actual file data, and the blame be "incidental". Which it really is. - As Ted already pointed out, you actually want to search for the point you're interested in, but when you start out and see the top of the file that generally gets annotated last, a natural reaction with the current interface is to wait for the annotations to happen rather than actually start looking at the code. Which is silly. You end up waiting for somethign that you don't even really care about.. Again, I think the basic issue is the same: by making the annotation data *so* prominent, the lack of it just forces you mentally to think that something important is missing. - Finally, the purely practical issue of "on a small screen, this would be almost impossible to use". Optimally, you should be able to see the whole (or at least the bulk) of the actual file content even if you only had 80-character lines in the blame viewer. And I just tested: if I make the blame viewer 80 characters wide when I look at a random kernel file annotation, I don't even see the "current line number", much less the actual file data. And remember: the file data was supposed to be the *primary* thing. If I make it 110 characters wide, I can see ~20 characters of the file data, which means that I can't actually make sense out of anything that is indented by more than two indents, and I usually can't even see the full function names - much less arguments - in declarations.. Anyway, all of these issues makes me suspect that the proper blame interface is to basically *hide* the blame almost entirely, in order to make the important parts much more visible, and in order to encourage people to start looking for the piece of code that they are actually interested in. Then, some *small* part of the annotation window (preferably on the right-hand side) should have some very basic blame info - possibly even just a "grouping hint" to see where the blame boundaries are. And only when you mouse over it or something, do you get the full data. I dunno. I'm horrible at actually doing GUI's, so you should take anything I say with a grain of salt. At the same time, I do know what *I* consider to be important (which tends to be unusual in a user), and I'd like to think that I have a clue about how people work. And I've always hated "annotate" in CVS, but git made it even worse by making the annotation data much bigger. (Yes, from a technical standpoint making the annotation data bigger is a good thign: git simply has more useful information than CVS does. But the lack of information in CVS actually makes the "stupid interface" better, if only because you don't waste as much space on it). But I'm not going to be able to actually do what I describe above. I can only hope to inspire somebody else.. Linus - To unsubscribe from this list: 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