Re: git-blame.el

From: Karl Hasselström <kha@treskal.com>
Date: Feb 1, 2007, 14:26 UTC
Message-ID: <20070201142638.GA12980@diana.vm.bytemark.co.uk>
In-Reply-To: <87veimxbc6.fsf@morpheus.local>

On 2007-02-01 14:21:29 +0100, David Kågedal wrote:

Show 11 quoted lines

> Karl Hasselström <kha@treskal.com> writes:
>
> >   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.

Hmm, probably, yes. But it'll be kind of limiting to not be able to run blame on a file that has local modifications. I think I understand why vc-annotate opens a new buffer ...

Show 6 quoted lines

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

Yes. I was thinking of exactly what "git log -p $hash^..$hash" produces. The Emacs windows should be split in two frames, with the commit details + diff in the lower frame, just like vc-diff.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle