Git – Should a Commit Message Mention the Modified File?

You should commit when ever your project compiles (and passes all UnitTests).

This way you'll commit every 2 minutes (in average). So you are only 2 minutes away from switching branch or leaving for home. This there is no nee to use the stash (most of the time).

This in best done in conjunction with TDD since this gives you two distinct events to commit: after you made the last (one and only failing) test "green" and after "refactoring", before writing the next test.

still I don't see the point of commiting that often, – Walfrat

The biggest benefit is when you rebase your changes to integrate with your upstream: git applies every commit in separation (unlike it does when "merging" where it only applies the resulting changes). This has some benefits:

1. since the commits are (very) small there is a very low chance for conflicts.
2. if there are conflicts its easy to find out what the result should be, since the changes are so small.
3. you can verify your conflict resolution by running your unit tests before continuing the rebase.
4. If you later have to find out when you introduced a certain behavior you can just search through your commit messages. The commit found only has the relevant changes. You don't need further investigation which changes in the commit are relevant.

in average I commit once or twice a day. I fail to see how I can perform meaningful commit on a lower scale. – Walfrat

When doing TDD the the end of the micro cycle is a somewhat "natural event" to commit:
You have your project in a deliverable state.

If there is a need to "rollback" you most likely want to return to such a state knowing that all features implemented so far really work. When doing TDD this typically is every 30 seconds, sometimes longer and about 2 minutes in average.

The commit message would describe the tests assumption on the production code it verifies.