[HN Gopher] Blamer.el: A Git blame plugin for Emacs inspired by ...
___________________________________________________________________
Blamer.el: A Git blame plugin for Emacs inspired by VS Code's
GitLens plugin
Author : hprotagonist
Score : 52 points
Date : 2021-10-25 14:42 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| na85 wrote:
| I note with pleasure the obligatory animated gif features nyan-
| mode[0]. The patrician's choice for unmet modeline silliness
| needs.
|
| [0] https://github.com/TeMPOraL/nyan-mode
| TeMPOraL wrote:
| Love to see it's still being used!
| CraigJPerry wrote:
| I've just adopted the dark matter anti-version of this - edamagit
| on vscode. It brings emacs' awesome magit tool to vscode.
|
| It has hardly any likes on the vscode repos just now but it's
| been solid.
| morelisp wrote:
| 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.
| nullspace wrote:
| 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.
| tehbeard wrote:
| 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.
| jakear wrote:
| 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...
| WorldMaker wrote:
| 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.
| morelisp wrote:
| > 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.
| ossusermivami wrote:
| c-x v g is vc-annotate btw: which is imo a bit better than
| magit-blame which is kinda hard to follow
| da39a3ee wrote:
| 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.
| brundolf wrote:
| 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
| TeMPOraL wrote:
| 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.
| morelisp wrote:
| > 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`.
| morgancmartin wrote:
| 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.
| oefrha wrote:
| 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.
| morelisp wrote:
| > the buffer is read-only in the Magit-Blame minor mode.
|
| Use `m` instead of `b`.
| lf-non wrote:
| Something similar for nvim:
| https://github.com/APZelos/blamer.nvim
| da39a3ee wrote:
| The GitLens VSCode plugin is nice, but
|
| (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.
| twism wrote:
| ah good ol' C-x v g
___________________________________________________________________
(page generated 2021-10-25 23:01 UTC)