Jeff King <peff@xxxxxxxx> wrote Thu, Apr 10, 2008: > On Sun, Apr 06, 2008 at 10:05:33PM +0200, Jonas Fonseca wrote: > > > stay up to date. Finally, add a blame view accessible from the command > > line (tig blame [rev] file), status view as well as the tree view (by > > pressing 'B'). > > Hi Jonas, Hello Jeff, > Thanks for all your hard work. I have really been enjoying the new > blame view; blame was the only reason I ever used git-gui, and now I can > stay in the terminal all the time. That is great to hear. > One feature that I have often wanted when using the blame view is to > restart the blame from the parent commit of a blamed commit. That is, > given a line like: > > 2007-08-22 19:36 Jonas Fonseca 776bf2a 15│ #include "config.h" > > I look at 776bf2a, and realize that there was some other interesting > form of the line _before_ that commit. So I want to start reblaming at > 776bf2a^. The current blame capability is very basic and this sounds like a good idea for extending it. > Below is an initial attempt at a patch, but it has some problems: > > - the interface is a bit klunky. Since commits may have multiple > parents, it seemed wrong to always just choose the first parent. > I chose '1' to reblame from the first parent and '2' from the second > (and obviously 3-9 could do the same). > > My thought was that the same functionality could be applied to the > commit viewer to jump to the parent. But maybe grabbing a string and > appending it to the commit id would make the most sense. Either that or there could be an option to show parent commit lines in the diff view à la gitk: Parent: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (Do something) Parent: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (Do something else) and then make pressing 'B' on one of them start it. At least this should solve the problem of having the option for all parents. Using '1', '2', ... or '^' + a number could still work as a short hand. > - it reloads the blame view with new parameters, which will put the > cursor back at line 1. It would be nice to stay at approximately the > same line (approximate because the line numbers will change; just > staying at the same line number makes sense to me). > > I tried a few things, but it looks like we throw out the line > numbers when we do a reload. I tried saving the line number and > trying to scroll to it afterwards, but there is some trickery > required because we have to wait until the view is loaded again. Is > there any sane way to do this within the current framework? There is currently no way to do this. Some views have their own hacks to restore the position. But a general way to preserve the position in a view across reloads is something that will come in handy for the status and staging area as well. > - opening a blame view, blaming a parent, and then opening the diff > viewer can cause a segfault. I assume I'm violating some assumption > through my open_view() call. Since the patch is only about 15 lines, > I'm hoping there's something obvious you can comment on. Oops. I will look into it when I get more time. Thanks for the ideas and the clean patch. -- Jonas Fonseca -- 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
