4 ms·
> One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Wo
by fmbb 6mo ago
> One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions.
Well isn't it typical that the person who wrote is also the person that merged? I have never worked in a place where that is not the norm for application code.
Even if you are one of those insane teams that do not squash merge because keeping everyone's spelling fixes and "try CI again" commits is important for some reason, you will still not see who _wrote_ the code, you will only see who committed the code. And if the person that wrote the code is not also the person that merges the code, I see no reason to trust that the person making commits is also the person writing the code.
- mrunkel 6mo agoCode merges are made by reviewers in my org, not by the author. Spend time educating your team about `git commit --amend` and `git push --force` on their own branches and you don't have to see any of that ugliness.
- fmbb 6mo agoSquash merges have two upsides: 1. I don’t have to see that ugliness. 2. Nobody has to force push and micro manage commits. If I recall correctly most code forges will add co-author trailers if someone other than the author squash merges.