Re: git-blame.el

Karl Hasselström [off-list ref] writes:

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

quoted

Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds. Plus a few minor fixes.

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.

Don't know why this happens.  I haven't seen it myself.

  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"?

Sure.  It's a trivial addition.

  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?

I saw it was discussed, but I don't think it was added.  Currently, it
probably makes most sense to verify that the file hasn't been
modified, and then switch to read-only mode while viewing the blame.

  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.)

This is almost as trivial as 2, since the hash is available, you can
simply run shell-command.

  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.

As in "git log -p", you mean?

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

Sorry Kalle.  I won't have any more spare cycles until next week.

-- 
David Kågedal