> One of Git's core value-adds is the ability to edit history
I didn't make it past this line. git is extremely good at keeping history immutable; it's also good at creating new, alternative histories and moving between them.
Editing history in git is also well supported and very commonly used, and git does it well. It's just not for absolute beginners, and the UI is occasionally not great. If git did not want you to ever change history, filter-branch, rebase, rebase -i, fixups, squashes and a bunch of other inclusions are odd, to say the least.
My point is, git doesn't let you edit history; it lets you make branches easily & the original history remains unaltered. It's trivially easy to detect altered history, and talking about 'editing history' gives the impression that repos are vulnerable to attack.
What wording would you suggest to refer to these kinds of operations? Replacing history?
You mentioned "altered" history, which to me isn't much different from "edited" or "modified", though maybe that was just a slip and not your preference?
There does need to be some term for it. If I push a reordered branch, I clearly did more than nothing, even if we don't want to call that modifying history.
I do question if any term will work perfectly, or if there is any full solution other than one learning git to an intermediate level before discussing it. The problem, as I see it, is that there are (at least) two concepts of history, there is the DAG of commits, where ancestors are older, and there are branch-heads where you can change what they point to in unrestricted ways (pretty much the reflog). I'm not sure English has a really good metaphor that's going to capture everything.
I didn't make it past this line. git is extremely good at keeping history immutable; it's also good at creating new, alternative histories and moving between them.