On one hand, I guess this looks nice. It's attractive and the mode is well written.
On the other hand, I have a hard time believing "the first line of the last commit to touch this line" is really such useful contextual information it needs top billing. I've noticed a major trend in the past 3-4 years of popping up as much contextual UI as possible by default in IDEs. I don't think it's unrelated to the decline in ability or willingness to just follow the damn code I've also noticed in the same time.
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.
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.
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
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.
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.
It looks nice and I can see why someone used to VS Code's GitLens would like to bring this over, it seems really seamless.
Personally, as a long-time magit user, I'm not sure I see any reason to make the switch. Can anyone more familiar with GitLens (possibly the author) provide any commentary on its differences with magit's blame functionality?
AFAICT, the only difference seems to be that the commits simply show on line selection instead of all at once, but there may be more going on here than I am noticing at first glance.
The difference is that the blame is shown all the time. magit’s blame has to be activated (magit-blame) and the buffer is read-only in the Magit-Blame minor mode.
Personally I find the feature distracting and turn it off (gitlens.currentLine.enabled set to false).
Of course, GitLens also has a separate blame mode.
(1) Very annoying that the default is to show blame all the time when the cursor moves to a new line. Who would want that? It just made me strongly dislike the plugin at first encounter, until I'd turned that behavior off.
(2) It also has a massively over-engineered `git rebase --interactive` buffer IIRC. That thing is fine as plain text with nice keyboard shortcuts, as in magit.
22 comments
[ 1.2 ms ] story [ 52.9 ms ] threadOn the other hand, I have a hard time believing "the first line of the last commit to touch this line" is really such useful contextual information it needs top billing. I've noticed a major trend in the past 3-4 years of popping up as much contextual UI as possible by default in IDEs. I don't think it's unrelated to the decline in ability or willingness to just follow the damn code I've also noticed in the same time.
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.
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.
Real world example: https://github.com/microsoft/vscode/blob/main/.git-blame-ign...
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.
I've mentioned in previous Emacs threads, if you aren't running with
In your magit minor mode maps, what are you even doing?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.
`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`.
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.
Personally, as a long-time magit user, I'm not sure I see any reason to make the switch. Can anyone more familiar with GitLens (possibly the author) provide any commentary on its differences with magit's blame functionality?
AFAICT, the only difference seems to be that the commits simply show on line selection instead of all at once, but there may be more going on here than I am noticing at first glance.
Personally I find the feature distracting and turn it off (gitlens.currentLine.enabled set to false).
Of course, GitLens also has a separate blame mode.
Use `m` instead of `b`.
[0] https://github.com/TeMPOraL/nyan-mode
It has hardly any likes on the vscode repos just now but it’s been solid.
(1) Very annoying that the default is to show blame all the time when the cursor moves to a new line. Who would want that? It just made me strongly dislike the plugin at first encounter, until I'd turned that behavior off.
(2) It also has a massively over-engineered `git rebase --interactive` buffer IIRC. That thing is fine as plain text with nice keyboard shortcuts, as in magit.