Sorry, I beg to differ. I think GitLens is hands down the most useful VCS plugin I've ever used in an editor. Every single day, I find myself reading a line or two of code and wondering who added / changed that line and why.

Of course, it's not perfect, but it's a pretty damn neat hack!

EDIT: As a secondary effect, it also gives me a reason to ask team members to write better commit messages: "Hey, I was just browsing through the code, and landed on this commit, but the message does not tell me why the change was introduced." That happens more often than it did before I started using GitLens.

Honestly, as useful as it is, it'd be so much better if we had better / more contextual diffing. So often it is just spams with the last styling/linting erasing useful context.

It's still text file/line based, having something that can ignore style changes and linting would be great, even being able to see properly when a function/method was first added and view the changes to that function/method, rather than just lines of text.

Semantic diffing would be great, but until then you want an ignore revs file: https://www.git-scm.com/docs/git-blame#Documentation/git-bla...

Real world example: https://github.com/microsoft/vscode/blob/main/.git-blame-ign...

I wish for something just slightly smarter than the current ignore revs format. For instance, I generally try to prefix all automated tool based commits with a wrench emoji. I realize you can automate building an ignore revs file by for instance grepping git log for that prefix, but it would be nice for an "ignore prefixes" as much as an "ignore revs" option.

> Every single day, I find myself reading a line or two of code and wondering who added / changed that line and why.

Me too - a line or two of code, out of maybe 300-500 read. And usually the most interesting commit is not just the most recent one, so I need to start switching back a few versions anyway. So I'm glad magit-blame-addition is only a `C-x v g` away, but I'm also glad it's not polluting my screen with noise the other 99% of the time when I'm focusing on reading the code and not mystified at its provenance.

c-x v g is vc-annotate btw: which is imo a bit better than magit-blame which is kinda hard to follow

Use the margin style (`c` in `magit-blame` mode) if you prefer `vc-annotate`'s default.

I've mentioned in previous Emacs threads, if you aren't running with

         ("<remap> <vc-diff>" . magit-diff-buffer-file)
         ("<remap> <vc-print-log>" . magit-log-buffer-file)
         ("<remap> <vc-print-root-log>" . magit-log-all)
         ("<remap> <vc-annotate>" . magit-blame-addition)

In your magit minor mode maps, what are you even doing?

The way I see it, contextual UIs are nice when they surface useful information; otherwise, they're just noise. Showing blame lines in "prime real estate" for contextual info? I'd personally call this noise. Usually, when I want to see which commits touched what, I want this info over a larger block of code.

I also found that commit header line is near-useless information[0] - it's too short to convey anything interesting. In my experience, almost all commits tend to belong to one of two categories:

1. The whole commit message is in the header line. Meaning the whole commit message is worthless anyway, and I'll have to skim the diff to learn anything.

2. There is a proper, multi-line commit message. That still means the header line alone is of limited utility.

Myself, I use Magit's blame functionality, which pops up a buffer annotating the whole file with blame information, grouping lines belonging to the same commit. That said, I still have fond memories for IntelliJ's blame, which put that data in a fixed-width column on the margin, showing author and date. It also colored the sidebar by commit age[1], which provides something much more useful in terms of contextual data: a qualitative indicator of age of pieces of code in the file. This kind of data is what contextual UIs are best for - data you mostly want to keep in corner of your eye, to get a feel about things.

--

[0] - I still like it displayed, though: it's easier to use as "visual hash" than date, author or commit hash.

[1] - I'm 90% sure this coloring was in IntelliJ, but I might have seen this in a different IDE.

> put that data in a fixed-width column on the margin, showing author and date

`magit-blame-cycle-style` (`c` when in blame mode).

> easier to use as "visual hash" than date, author or commit hash.

Seems like it should be possible to color the margin based on the hash to get exactly this rather than a poor approximation, but looking over the blame code you'd need to do it by hacking the overlay after application, it would be nicer if it supported something like `:eval` in the format a la `mode-line-format`.

> `magit-blame-cycle-style` (`c` when in blame mode).

Thanks for that! This made me check the help for magit-blame and magit-blame-read-only modes, and I discovered various keybindings and features I was unaware of, like removal and reverse-blaming.

But the most important think I just learned is that the styles are customizable, via `magit-blame-styles`. Skimming the docs, it should be trivial to reproduce the kind of visualization I'm looking for.

I usually find the time stamp and commit message more useful than who made the change. They provide useful context, almost like a comment, and for example if I'm trying to locate a regression I can immediately see "did this line even change in the past week? no? that must not be it then" And move on

Yeah, I think people differ a lot over this. E.g. there are lots of people who seem to want as much info in their shell prompts as possible, and all sort of system resources monitors on display all the time. I'm not an extremist on this -- not having current dir, current branch and an indicator of unstaged changes in my shell prompt would make me uncomfortable -- but I share your suspicion that there's an inverse correlation between wanting unnecessary context on view and experience/skill as a software engineer.