Just to answer on “short descriptive concise”,
for me it is really most important that it actually describes the code change in that file, I don’t go by the logical block of changes across files view that much, I prefer a micro commit per file, let branches and pushes decide what is a set of increments that make a compilable version. You can reconcile things for a PR with a single commit ofc, that is separate issue from “personal” use you have on you dev branch.
I’d argue short is not necessarily better, argued paragraph of why the change and how it happens is often precious doc, the first line should be concise, not the commit message (esp if it’s a hard change). The traces stay in the repo, you can go back to them. It is not antinomous from documenting and keeping source code doc up to date, but documenting change is the VCS is as good a place as any else.
Teaching, I give the ideal goal, and discuss these different chapels of logical commit/fine grain etc… but then in practice I only really make “nasty” remarks to students that have commit messages that say “updated” or such noise.
So what I want them to remember is really what I put as answer to the question : “anything as long as it really tries to describe the actual change”.
True discipline comes from repos with actual rules to commit message format, e.g. Gnu or Eclipse projects, with lots of rules to sign your commit and make it be accepted.
But teaching students to first use git ? I want them not to be afraid to commit and revert and branch all ways to heaven. So not too many rules at first regarding commit messages, that is not the point.