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.
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. ;-)
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
-
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