magit-blame

152 views
Skip to first unread message

Yuri D'Elia

unread,
Apr 26, 2015, 7:45:08 AM4/26/15
to ma...@googlegroups.com
Hi everyone,

I've been trying hard to use magit-blame, but for most purposes I find
it next to useless.

For files with just a few block changes, I do like the output of
magit-blame, as it shows the editing chunks more easily.

But in reality, in mature projects contiguous changes are often only 1-2
lines long, making the interspersed annotation a major distraction (that
is, the source is almost unreadable). As a result, I never actually use
magit-blame.

I sometimes resort to vc-annotate, but it also has it shortcomings with
git. It has overlong side annotation, so long it requires twice the
horizontal space to be able to *read* the actual buffer.

It also tries to do rainbow coloring for the age of the changeset, which
is not a bad idea per-se, but by doing it on the *content* as opposed to
the annotation, it kills font-locking (I just disabled it). If it was
done on the annotation instead, age coloring would have been much more
useful.

I generally give up and just use 'tig blame'. It has compact, side
annotation, which is actually colored by commit id. I find this to be
much more useful than commit 'age', as it's usually more convenient to
see lines from the same commit, while age is largely irrelevant in
mature projects.

It would be nice to have the same kind of output directly in magit.
Does anybody else share the same view?

Jonas Bernoulli

unread,
Apr 30, 2015, 6:58:36 PM4/30/15
to Yuri D'Elia, ma...@googlegroups.com
> But in reality, in mature projects contiguous changes are often only 1-2
> lines long, making the interspersed annotation a major distraction (that
> is, the source is almost unreadable).

On magit's next branch you can press `t' to only separate chunks
with thin lines instead of headings. (Then press `RET' to see the
full information about the commit that added the lines at point).

> It would be nice to have the same kind of output directly in magit.
> Does anybody else share the same view?

I intend to eventually look at how other tools do it and then come
up with a synthesis. In the past I have looked at various emacs
blame interfaces and found all of them to be insufficient (including
magit-blame).

Yuri D'Elia

unread,
May 1, 2015, 10:53:49 AM5/1/15
to ma...@googlegroups.com
On 05/01/2015 01:02 AM, Jonas Bernoulli wrote:
>> But in reality, in mature projects contiguous changes are often only 1-2
>> lines long, making the interspersed annotation a major distraction (that
>> is, the source is almost unreadable).
>
> On magit's next branch you can press `t' to only separate chunks
> with thin lines instead of headings. (Then press `RET' to see the
> full information about the commit that added the lines at point).

Good to know, but only marginally better.

>> It would be nice to have the same kind of output directly in magit.
>> Does anybody else share the same view?
>
> I intend to eventually look at how other tools do it and then come
> up with a synthesis. In the past I have looked at various emacs
> blame interfaces and found all of them to be insufficient (including
> magit-blame).

Some thoughts here if you want some more pointers.

Even though I don't use it since years, I never had a better experience
compared to p4v's file blame/history tool (a real kudos to Perforce
here). I rarely use GUI tools, but p4v made a *real* compelling
argument. I consider current git frontends to be mostly garbage by
comparison, and the devil is in the fine details of the UI.

In git land, I still find myself using 'tig' browse/tree/log and blame
modes too much (I spawn a terminal instead of staying in emacs). It's
very fast and generally well thought off, although for strictly browsing
diffs and files it cannot compete to staying in emacs.

The blame mode is very good for visualization, although it's not
excellent when it comes to version switching (that is, you can go to the
parent commit, but the current line is not matched across versions, and
you cannot forward).

I think I said everything I had in mind about vc-annotate.

In emacs, I use git-timemachine occasionally. However, like for tig, it
also lacks same-line alignment when switching through versions, which
makes it quite annoying for the use I had in mind.

What about github's blame mode? I think it's decent, but could be
better. Again, the use color for the age in that thin strip. Not really
useful, but fortunately doesn't waste space. Color-banding the
background color of the left annotation would have been superior and way
more visible. I like the idea of having the title of the commit in
there, but it's not going to work for emacs. author/date/short commit id
are more useful and compact.

Trac also fails at coloring, using commit age. But click on a commit
version/hash, and the lines from the same commit are highlighted. *Very*
useful. They also popup the commit log, which eats too much space
unfortunately. If it was done in a header/footer instead I would have
loved it.


Reply all
Reply to author
Forward
0 new messages