[Benjamin_Dobell]

Are you pushing the commits with errors? Are you merging the commits with errors? If both of those are true then this sounds like a process issue.

Git makes it extremely easy to edit history, with the ability to amend any commit; even several commits back with simple CLI tools like `git rebase -i <ref>`.

However, what it doesn't like you doing is ripping the rug out from other people i.e. editing history team members are basing their work on.

The entire purposes of distributed version control is that development should always happen on a branch. Whether that's a local branch, or some temporary pushed branch (pull/merge request branch etc.) In both cases you can safely rewrite history.

However, `master` (or whatever mainline branches you have) should never contain simple mistakes (e.g. non-compiling code), because the code should have been reviewed before being merged. Of course bugs (non-simple mistakes) will happen, and these ought to be fixed in future commits. Bugs that make it into pre-release or release builds (i.e. `master`) shouldn't be edited out of history or forgotten.

[nobody271]

Hmm, okay, I should learn how to rebase then.

The biggest part of my problem is a total lack of commit discipline but there are times when I'm working on a branch where my commits don't tell a clear story (changed something then changed it back because I decided to do it a different way). That's when I most wish for better ways to tell that story.

I feel like an idiot for not knowing rebase could solve some of this for me. ...will definitely try it next time.

[Nullabillity]

That back and forth is the most important part of the story! It shows that you thought through multiple approaches to the problem, (hopefully) why they didn't pan out, and they give someone else a starting point for returning to that approach in the future.

It isn't exactly rare that I go through the blame history on some project to find out why something was done in a way that seems stupid at first glance, just to get stuck on a giant squash commit saying "Implemented X".

[Benjamin_Dobell]

"back and forth" is not the same thing as "all kinds of mistakes".

No-one cares about stray keystrokes other developers make, it's just noise.

Yes, we absolutely care about the design of the software we're working on, and that's what commit messages, self-documenting code, comments, issue trackers and project management (planning session etc.) are all for.

When you squash commits in Git the default generated commit message is even to merge together all your previous commit messages. Now is your chance to look at those old messages and change "Did X" to "Attempted X, but didn't work because Y".

When I'm investigating when and why some code was implemented the way it is; I don't want to look at a Git blame trying to find when something was changed, just to see that the most recent change was reverting some earlier messing around. Just to git blame again starting from just prior to said messing around, just to see the same thing again - noise is bad!

[Nullabillity]

> No-one cares about stray keystrokes other developers make, it's just noise.

Sure, and `git commit --amend` is fine for those cases.

> When I'm investigating when and why some code was implemented the way it is; I don't want to look at a Git blame trying to find when something was changed, just to see that the most recent change was reverting some earlier messing around. Just to git blame again starting from just prior to said messing around, just to see the same thing again - noise is bad!

I guess that depends on your setup. My Emacs is set up so that `b` is "reblame from before this change". GitHub's blame UI has a similar button (though that, sadly, doesn't preserve in-file context).

At that point the cost of the "noise" is more or less zero.

[heavenlyblue]

What if my repository is linked to a CI process that deploys the live code? And tb change needs to be done “now”?

If you are working for a larger company where processes are clearly defined, then it’s good for you and that feature is not needed. But you are loosing all of the agile feature of git in the first place.

In my situation squashing history takes away my other ability to use git as a wiki of “things that didn’t work out”. It’s important to keep that.

[Benjamin_Dobell]

> git as a wiki of “things that didn’t work out”

Wouldn't a wiki be the best solution for that? Git is a software development tool, not a design or project management tool.