I've thought about writing a subversion compatibility scripts overlay for git, just to make my live easier.
I've thought about writing a subversion compatibility scripts overlay for git, just to make my live easier.
Unless you are using git as a centralised SCM, the concept of a linear revision doesn't quite match up.
Of course many workflows between different branch and people do eventually end up with there being a "master master" (or a main main to use more up-to-date terminology), and workflows for single dev projects naturally do, perhaps in those cases you could wrap relevant git commands in something that increments a build number stored in a file before relevent actions.
It perhaps do away with a simple increasing revision number and use the date of merge on that branch, which would at least always be increasing.
They're using git with Gitea or Github, or Gitlab, there is a defacto centralized master.
Though it isn't git's failing when people use a distributed SCM in a centralised manner and expect it to be optimised as such!