The problem with magit blame (Re: magit-blame)

[Yuri D'Elia]

On Sun, Apr 26 2015, Yuri D'Elia <wav...@thregr.org> wrote:
> Hi everyone,
>
> I've been trying hard to use magit-blame, but for most purposes I find
> it next to useless.

I've been using mo-bit-blame[1] lately, but I still think magit
*deserves* a better blame mode.

I'm dumping this here to make it more visual:

https://www.thregr.org/~wavexx/tmp/1460641851.png

The source is unreadable. And if I toggle the headers, it's useless.

A good blame view? This is "tig blame":

https://www.thregr.org/~wavexx/tmp/1460642181.png

Note how the same commits are color-coded with same values with a
cycling palette. Notice how compact the information is on the side.

mo-git-blame still doesn't font-lock as I would like, and the
information is not squeezed enough (unfortunately, it's hard to
customize), but it's still much better than the current magit mode. And
it's incremental as well.

Any chance mo-git-blame could actually replace the current blame mode to
encourage contributions? I've promised myself to modify mo-git-blame to
colorize the commits properly, but I didn't get to it yet in months. I
hope somebody could step in.

[1] https://github.com/voins/mo-git-blame

[Jonas Bernoulli]

> Any chance mo-git-blame could actually replace the current blame mode to
> encourage contributions?

No chance. But we can take inspirations from it (and tig, git-blame.el,
vc-annotate.el, and others) to implement *alternative* visulization
methods.

I don't think any of the various approaches are objectively better than
the others. In some case one works better and in other cases another.
It makes a difference whether the average chunk is larger than 1-2 lines
or not and how wide windows usually are, just to mention two factors.

And since magit-blame.el is well integrated with the rest of Magit,
while mo-git-blame.el is not, it does not make any sense to replace the
former with the latter.

> I've promised myself to modify mo-git-blame to colorize the commits
> properly, but I didn't get to it yet in months.

Likewise I have intended to improve blaming for a long time. But it's
not a priority because the current implementation works, while other
equally important features are missing completely.

> I hope somebody could step in.

So yeah, it's on my TODO list, but I don't know when I'll get to it.
If someone else wants to take a shot at this then I welcome that.

Any implementation should clearly separate (1) calling git and parsing,
(2) visualization, and (3) integration into the rest of Magit.

Ideally the parsing would be improved a bit before even beginning to
work on the visualization.

Any implementation of the visual part should take into account that it
is only intended to be one among many. Also it should be possible to
switch the style without having to call git again, which means that
abstractions have to be added which currently are missing.

Best regards,
Jonas

[Yuri D'Elia]

On Thu, Apr 14 2016, Jonas Bernoulli wrote:
> I don't think any of the various approaches are objectively better than
> the others. In some case one works better and in other cases another.
> It makes a difference whether the average chunk is larger than 1-2 lines
> or not and how wide windows usually are, just to mention two factors.

True, yes. I tried repeatedly vc-annotate, but I honestly don't like it
at all. Age-based coloring is useless. Overlong annotation that requires
2x the horizontal space to work (at least with git, with cvs/svn is
somewhat better). It also messes with the font-locking of the buffer,
which is another issue.

By experience, mature code bases tend to have very small interspersed
chunks. For this scenario, as you saw, magit blame becomes unreadable.

commit-based palette coloring has the nice advantage that allows you to
spot a single line change interspersed in a previous large chunk very
easily. You can see exactly how a single commit flows across the buffer.

tig on the terminal is limited with the palette: it's 5 usable colors
don't do it justice. But you can obtain very distinguishable palettes up
to ~20 colors which on emacs+x11 would limit collisions to a much lesser
extent.

> And since magit-blame.el is well integrated with the rest of Magit,
> while mo-git-blame.el is not, it does not make any sense to replace the
> former with the latter.

I've been using the console all the time for tig blame, so heh, the
current integration of magit-blame doesn't mean much for me even though
it's right there.

I find "blame" incredibly useful to narrow down commits as opposed to
reading logs. It makes me start from the code as opposed to reading the
log messages. It shows the commit in it's own context as opposed to
reading a patch.

I was spoiled by this method by p4v (the perforce gui). p4v actually
allows blaming at specific revisions easily. You can easily go from the
current file+line, to the change that you're interested in, to the blame
view at the time the change was committed. Moving back/forward in the
commit history was just one keystroke away. *Extremely* useful to see
the evolution of the code around the change that you're interested in.
It has truly changed my way of interacting with the source history,
making it 20x more valuable. So yes, I do really miss p4v :(

With tig you can somewhat navigate the blame by using ',' (parent
commit) on the commit you're interested in. Unfortunately, that's pretty
much it.