Valid, but you lose the lived history that comes with the audit log of it being actual review back and forth and CI runs vs lost to a developers machine and only a relic in the commit log. I can see both sides, though.
Valid, but you lose the lived history that comes with the audit log of it being actual review back and forth and CI runs vs lost to a developers machine and only a relic in the commit log. I can see both sides, though.
Can you elaborate about the practical value of having the history of back and forth, in a PR or even in the commit log? In my 20ish years of experience, I can’t recall a single instance where I’ve solved something thanks to having this work-in-progress state persisted in the repo history.
It’s exclusively been the other way around where having a smaller number of larger squished commits (post merge) that’s made the project be more maintainable.
It's not about having it in the commit history. I've seen a few cases where the back and forth revealed that the AI reviewer was offering bad advice (and a few others where I suspect bad local AI advice is why people keep sending me the same category of mistake).
People usually squash merge anyways
Actually not, it is similar debate like rebase or merge.
e.g. I don't squash, I prefer to see full history, not redacted one.