Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When inheriting a project, you use git blame a lot. Who wrote it, when it was written and any hints as to why it was written. If it has a task number like "fixes #1402" and you still have access to the issues, that's great.

If it is like "f*ck python" or "lol java sux" that's a good indication that it was a syntax problem or a trivial mistake.

If it is like "a" or "aaa" or "x" it's just useless and you are on your own.



> If it has a task number like "fixes #1402" and you still have access to the issues, that's great.

If. The flip side is that when you don't have the issue tracker (I'm unclear as to whether they deleted it, or it just didn't come along when the product was acquired), it's maddening. "This [massive, opaque] change fixes #123" "...gee, thanks; that tells me loads."

Ask me how I know.


> When inheriting a project, you use git blame a lot

Obligatory plug for `git log -p`, which is a much better tool for finding out how changes happened to a file.

You can also use `git log -p --follow` with a single file to track the file across renames and moves.


When the first line of the commit is just "Fixes 1429", that's annoying. It belongs on a subsequent line.

I can look through the list of commits for recent changes that seem like they might have caused a new bug, but a list of numbers is no help at all there.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: