Re: git-blame.el

On 2007-01-31 14:04:06 +0100, David Kågedal wrote:

I've tried it, like the concept of in-buffer blame and the pretty colors, and have a few comments and suggestions:

  1. For some files, but not all, emacs is unresponsive (and consumes
     lots of CPU) right after git-blame-mode is activated. Once
     git-blame has finished, it becomes responsive again, but this
     kind of defeats the whole "incremental" idea.

     This is most easily seen by holdnig down Ctrl+N or similar, to
     make the cursor move constantly.

  2. Getting to see the sha1 of the commit is not so useful when it
     can't be selected for copy-pasting. Maybe a keyboard shortcut for
     "copy-sha1-to-kill-ring"?

  3. Even after I've edited a line, or added a new line, they continue
     to be attributed to the same existing commits. They should either
     have no attribution, or possibly just "local edit" or something.
     I seem to recall this kind of functionality for git-blame being
     discussed very recently?

  4. It would be nice with a keyboard shortcut that (in a new buffer)
     printed more details about the commit under the cursor, kind of
     like the output from git-log. (Having this available would
     obviate the need for (2).)

  5. It would be nice with a keyboard shortcut for displaying the
     commit under the cursor in gitk. (For extra points: successive
     uses of this command should reuse the same gitk window if it's
     still open.)

  6. It would be nice with a keyboard shortcut for displaying (in a
     separate buffer) the diff to that file introduced by the commit
     under the cursor. This could be combined with (3) by having
     commit details followed by diff.

Oh, and try to have it done by Monday. ;-)