4 ms·

I'd rather see a TODO in the source file than in the commit message because of discoverability issues with commit messages. Maybe that can be fixed? If I need

I'd rather see a TODO in the source file than in the commit message because of discoverability issues with commit messages. Maybe that can be fixed? If I need to git blame the right line, and while ignoring miscellaneous commits like formatting changes, renames, and additional comment additions, then I'm probably not going to find the commit message. Also, if you do all of that just to find a vague commit message, then why bother digging next time? Best tech-debt tracking I've seen is in the form of TODOs with mandatory links to the issue tracker (thanks to a silly regex pre-commit/pre-submit check) coupled with a team culture of adding such TODOs, as just adding the regex check will just cause lazy and sloppy engineers to not add a TODO at all, especially when facing pressure from other teams.

sublinear 1y ago
Maybe this is what you're thinking of? git log -pM --follow --stat -- path/to/your/file This will get you all the changes a file has gone through. You can also add --ignore-all-space if that's a problem.
- dietr1ch 1y ago
  No, I knew there's some trickery to avoid part of the noise in git, but it's not enough as I won't be looking at that log or blame everytime I read a file. Using a TODO comment still seems better to me. A TODO surfaces details where it wouldn't even occur to me that there's something interesting hidden in the log. Trying to find them feels like smashing the action button everywhere to get a random secret in a game, like secret doors in rtcw or finding stuff with the shovel in zelda.
  - sublinear 1y ago
    Do you not use an IDE? It's fairly trivial to run macros or add something to the command palette. Maybe some personal scripts you have been honing over the years? Usually strong opinions like this come with a more developed workflow.
    - dietr1ch 1y ago
      Well, I guess emacs might qualify as an IDE. Magit is great, but my point about discoverability in practice still stands. I won't be looking for logs from all files, and logs only show recent changes, so long foretold issues like scaling or reasoning won't be there either.

sublinear 1y ago

Maybe this is what you're thinking of? git log -pM --follow --stat -- path/to/your/file This will get you all the changes a file has gone through. You can also add --ignore-all-space if that's a problem.

dietr1ch 1y ago
No, I knew there's some trickery to avoid part of the noise in git, but it's not enough as I won't be looking at that log or blame everytime I read a file. Using a TODO comment still seems better to me. A TODO surfaces details where it wouldn't even occur to me that there's something interesting hidden in the log. Trying to find them feels like smashing the action button everywhere to get a random secret in a game, like secret doors in rtcw or finding stuff with the shovel in zelda.
- sublinear 1y ago
  Do you not use an IDE? It's fairly trivial to run macros or add something to the command palette. Maybe some personal scripts you have been honing over the years? Usually strong opinions like this come with a more developed workflow.
  - dietr1ch 1y ago
    Well, I guess emacs might qualify as an IDE. Magit is great, but my point about discoverability in practice still stands. I won't be looking for logs from all files, and logs only show recent changes, so long foretold issues like scaling or reasoning won't be there either.