Re: git-blame.el

From: David Kågedal <davidk@lysator.liu.se>
Date: Feb 1, 2007, 13:21 UTC
Message-ID: <87veimxbc6.fsf@morpheus.local>
In-Reply-To: <20070201131213.GB11611@diana.vm.bytemark.co.uk>

Karl Hasselström <kha@treskal.com> writes:

Show 16 quoted lines

> On 2007-01-31 14:04:06 +0100, David Kågedal wrote:
>
>> 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.

Show 5 quoted lines

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

Show 9 quoted lines

>   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