I don’t quite understand what you mean. As I wrote I write my PR message as the commit message. That is one thing that is also very important for me. Write in t

I don’t quite understand what you mean. As I wrote I write my PR message as the commit message. That is one thing that is also very important for me. Write in the commit message why something changed. If the PR gets so damn big that it is so much to explain everything than it’s quite frankly too big. From my experience the follow up commits for fixes or code review changes boil down to messages like “fix stupid bug”, “adjustments after code review”, etc. which are also not helpful when looking for the why. But I honestly understand what you mean. I’m just saying that limiting down the number of commits and the size of changes in them helped me over the years. I also don’t do it when I start of from a white paper. Only when the project enters the stage when PRs plus checks help mitigate potential bugs etc.