4 ms·

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

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 5y ago
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 5y ago
  Semantic diffing would be great, but until then you want an ignore revs file: https://www.git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://www.git-scm.com/docs/git-blame#Documentation/git-bla... Real world example: https://github.com/microsoft/vscode/blob/main/.git-blame-ignore https://github.com/microsoft/vscode/blob/main/.git-blame-ign...
  - WorldMaker 5y ago
    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 5y ago
> 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 5y ago
  c-x v g is vc-annotate btw: which is imo a bit better than magit-blame which is kinda hard to follow
  - morelisp 5y ago
    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?

tehbeard 5y ago

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 5y ago
Semantic diffing would be great, but until then you want an ignore revs file: https://www.git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://www.git-scm.com/docs/git-blame#Documentation/git-bla... Real world example: https://github.com/microsoft/vscode/blob/main/.git-blame-ignore https://github.com/microsoft/vscode/blob/main/.git-blame-ign...
- WorldMaker 5y ago
  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 5y ago

> 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 5y ago
c-x v g is vc-annotate btw: which is imo a bit better than magit-blame which is kinda hard to follow
- morelisp 5y ago
  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?