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

That's an interesting point, but it seems like one among many very good arguments for "right-sized" or "logical" commits, i.e. not 10 similar-shaped bugfixes and also not one-line no-context diffs -- how big should the PR and merge commit be though? Maybe you put the 10 similar-shaped bugfixes together into one PR because they review together easily, but each fix is its own commit, because they all logically stand on their own.

Your use-case is actually the cause of a common rule I've seen at work of requiring a ticket reference in each commit message, which allows looking up the original ticket and associated PRs, along with any commentary & discussion at the time the commit was merged.

On a big code-archeological dig, I often follow a path like run blame -> look at the diff -> pull the ticket reference -> find ticket in issue tracker -> read its description & comments -> find linked PR #'s in the ticket tracker -> open PRs & read diffs and comments -> repeat for linked issues if needed (and then as often as not still end up baffled)

One team actually kept an old redmine VM instance running mostly based on my personal use long after we'd migrated to JIRA, so... I think my approach may be a little unusual! At the least, doing better sized commits would a huge step for every case involving blame.



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

Search: