Hacker News Reader

Comment by VadimPR | Hacker News Reader

In my way of working, the 'why' can go into the overall PR and the 'what' into the individual commits. Both are important - the reason for changes and a concise summary if what you've done.

View on HN

PRs are not easy to read in the commit history, a year later a commit message is mostly flat without context.

Depends on how you merge - I prefer squash (yes, controversial). If you do merge commits, then I agree individual 'why' needs to be within the commit.

Not to make this a merge strategy debate, but this is most of the reason why I’ve opted for squash merging for my team. I’ve been happy for quite some time.

I'm not against squash commits, yet assuming you're using it to squash an entire PR into a single commit (so that you get a linear history) and given that you also prefer that "the 'why' can go into the overall PR and the 'what' into the individual commits", then you might end up with a 'what' part that can be hard to understood, that's because squashed commits do not point to the exact code change that they originally referred (unless of course the entire PR is very small).

As I always say in these conversations, PR descriptions and comments are ephemeral. Your git history should be forever, but you’re not guaranteed to be in the same repo on the same host for eternity.

I have already worked on multiple projects that got handed to us as a .git/ folder. Commit messages referencing non-existent issues abound.

I now make my whole team ensure that nothing crucial is left to live in the PR alone.

Reply on news.ycombinator.com