Hacker News Reader

Comment by chapterjason | Hacker News Reader

You literally described git blame usage in almost every editor which supports git properly.

Yes and no. Git blame is great yes, but it's still rather crude. If three commits changed one condition; it only shows the top commit. Getting a full sense of the history of a function over time is far less ergonomic.

The tech and data-structure is there; but the common UX is not quite expressing the data in a sophisticated manner. It doesn't help that the default diff algorithm is rather crude as-well.

git blame falls apart on someone running a new linter config across the project or doing some refactoring work.

In GitHub and vim at least you can dig past those commits to see earlier relevant commits. I'm sure there are more tools that allow this.

Some tools will automatically ignore commits in a .git-blame-ignore-revs file. Git itself can "blame --ignore-rev <hash>" or "blame --ignore-revs-file <file>" since version 2.23.

  git commit -m "Autoformat source files"
  git log --format="# %s%n%H" -1 >> .git-blame-ignore-revs
  git add .git-blame-ignore-revs
  git commit -m "Ignore autoformat commit in blames"

  cat .git-blame-ignore-revs
  # Autoformat source files
  0a1b2c3d...

  git blame --ignore-revs-file .git-blame-ignore-revs code.src

Git can use it automatically too:

  git config blame.ignoreRevsFile .git-blame-ignore-revs
  git blame code.src

Though git-blame may fail or crash if blame.ignoreRevsFile is set but the file is missing (hence "config", not "config --global"). Since version 2.53, a configured ignoreRevsFile can be missing if the value starts with ":(optional)".

Reply on news.ycombinator.com