Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

Re: [ANNOUNCE] tig-0.11

From: Jonas Fonseca <hidden>
Date: 2016-06-15 22:44:28

Jeff King [off-list ref] wrote Thu, Apr 10, 2008:
On Sun, Apr 06, 2008 at 10:05:33PM +0200, Jonas Fonseca wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help