Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of not only the author's work but also other people's. Using merge almost never results in any sort of loss and is easier to work with for those who still don't quite understand the risks.

You are associating the use of `amend` and `fixup` with force push. It's perfectly fine to rework your commit history locally and even force push to your own local branch. It should never be possible (except to people administrating your repo) to force-push to any public or even shared branch.

Nobody should be able to force-push to master (or any public branch) except on specific occasion. In that case, someone is authorized, performs their specific action and then get de-authorized.

This is pretty basic.

"Force push" is something that should be restricted to a very few senior people anyway; once you do that, you can't rewrite shared history any more and a lot of the worries go away.

This is a great way to get me to clutter the shared repo with throwaway branches that I’ll later replace (deleting the old one—if you let me).

This is fine! This is a normal part of several popular git workflows. After all, a branch is just a pointer to a commit.

(Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend heavy: https://gerrit-review.googlesource.com/Documentation/intro-g... )

I thought you meant blocking all force-push. Shared branches should absolutely be protected (with an “in case of emergency, break glass” option)

Meanwhile the biggest issues I actually see in novices are when their IDE presents them with buttons that don't coincide with a single version control action (can you guess what "sync repo" will do?) and using those puts their checkout into a weird state.

Usually when using the commands directly they're more careful, but have the mindset "an IDE wouldn't intentionally break something so this button must be safe to click".

Custom terms on top of git is a bafflingly bad decision.

IDEs in particular should expose the details all the time, and show the command that's being run, so it can teach people passively instead of misleading them and leaving them stuck when it breaks.

totally agree here. commits are not for saving "your-current-work". Its about marking a definite step of change in the realm of the project itself.

making commits atomic is harder because we tend to just write code, without first breaking up the requirement into atomic pieces

Commits are for saving your current work. Commit early, commit often. Just clean them up when you're done!

Don't push half-baked work on other people! You waste their compute cycles needlessly, from now until the end of time.

I sometimes wish git supported hierarchical commits.

I.e., git can retain two representations of a sequence of commits: the original sequence, and also a larger commit that (a) produces the exact same code change as the sequence, and (b) has its own commit message.

Isn't that what a branch and a merge commit do?

Yep, as long as you use "--no-ff" to force a merge commit (and presumably edit the merge commit message instead of just using the default).

For viewing history you can use "git log --first-parent" to view only those merge commits, which should satisfy the people who love a linear history, without actually losing the intermediate commits.

I have entertained similar thoughts, but then on the other hand people already, and with some righteousness, criticize git for being too complex. It also requires careful assessment where the wormhole ends, how many levels of grouped commits should exist.

Then I remember that I have enough trouble getting a few dozen people together to write well formed and understandable commit messages for one level of commit messages alone. This scheme would require people to extend more energy on constructing commits which is at best something very few care about.

Then there are tickets and other corresponding information, but they could rot for all I care, as they so often do, unless a decent commit log is in place.

FWIW, Mercurial has this, and calls it changeset evolution:

https://www.mercurial-scm.org/doc/evolution/