4 ms·

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 centraliz

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

dmitshur 2y ago
Hopefully this is mostly intended to rewrite/polish local history, before it’s pushed upstream.
- thunky 2y ago
  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.
  - corytheboyd 2y ago
    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.
    - mvonballmo 2y ago
      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.
  - whoomp12342 2y ago
    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
Uvix 2y ago
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.
- pragma_x 2y ago
  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.
  - Uvix 2y ago
    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.
- whoomp12342 2y ago
  yeah but theres no reason you have to do it that way. Just make your own local branch and squash merge it into a singular commit when ready

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

dmitshur 2y ago

Hopefully this is mostly intended to rewrite/polish local history, before it’s pushed upstream.

thunky 2y ago
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.
- corytheboyd 2y ago
  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.
  - mvonballmo 2y ago
    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.
- whoomp12342 2y ago
  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

Uvix 2y ago

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.

pragma_x 2y ago
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.
- Uvix 2y ago
  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.
whoomp12342 2y ago
yeah but theres no reason you have to do it that way. Just make your own local branch and squash merge it into a singular commit when ready