design flaws as a feature: I like that rewriting git history is hard. immutable history is a good thing from an auditing perspective when you are in a centralized flow
There's no reason it needs to be hard in my branch before it gets merged, though.
And with the way Git stores information, sometimes you don't have any option but to rewrite history. e.g. when something changes on a committer identity, you have to rewrite all of their commits since that information is denormalized.
Now that's interesting. Are you talking about the commit author data, or something else?
FWIW, this sounds like the kind of thing that signed commits would solve. If the coder/user commits anything that isn't signed, they can't push it into the origin repo in the first place.
Yes, commit author data is what I was referring to. Both name and email address changes sometimes need to be retroactive, especially in corporate environments using GitHub or Azure DevOps.
This looks like a nice tool, but I agree with GP because as a reviewer I don't care about a "clean" commit history in a branch I'm reviewing. I care about what's changed, and imo the request description/annotations can describe that in plain language better than a commit history can tell a story.
You need to look further ahead than that though. A sane git history makes debugging much easier. When you bisect your way to a problem area, sure is nice when the suspect lines of code fall into a 10 line change commit with a nice message and body providing context. I’ll let it slide if the PR/MR has a lot of good context, because it’s trivial to link those back to commits/lines.
I also think we should be thinking more long-term. How understandable is the history when you're trying to figure out why something changed? I usually try to tell the story of what changes are being made rather than treating every clump of commits as a "PR" that's just going to be squashed together anyway. I think a lot of valuable information is lost by doing that. But I realize that that train has left the station for most, so I'll just shut up now.
I've always seen the clean commit stuff as a "I'm a junior and need to figure out how to logicaly lay out my thoughts" and push people away from uni commit model. clean commit purists take it a bit too far
