6 ms·

‘git blame’ is often more handy for finding the reason that the change was made, assuming you know the location of the bug. It tells you the commit and the comm

• kemayo 1y ago
  > assuming you know the location of the bug Well, yes. But `git bisect` is often the quickest way to find that, in a complex system.
• geon 1y ago
  Blame doesn’t help when the same code has been changed multiple times since the bug was introduced.
  • carlmr 1y ago
    While true, this is one reason I always introduce automated code-formatting early on. It makes git blame a bit more useful.
    • chrismorgan 1y ago
      Automated code formatting, in my experience, never decreases diff sizes, and frequently increases them. Some of those diff size increases support git-blame, some of them hinder it. Around the boundary between two possible formattings, they’re terrible. Code formatters do tend to force some patterns that may make the line-oriented git-blame more useful such as splitting function calls into many lines, with a single argument on each line; yet that’s not about the code formatter, just the convention. (And the automatic formatters choose it because they have no taste, which is necessary to make other styles consistently good. If you have taste, you can do better than that style, sometimes far better.)
      • carlmr 1y ago
        Depends on the language and the available formatters really, I find the black/ruff formatting style in Python to be very consistent, which helps with git blame. For C++ there's no good default formatter for "small diffs" since they all, as you say, add random line breaks dependending on position of parameters and such. With style you can do better, but having style is impossible in anything except single developer projects.