I looked at a few ideas, if something like the svn numbers could be
One approach would be to have a tag on each commit. That would mean that
r54123 would be a replacement for the sha1 in almost all (if not all)
Not tested, but likely that the server can add the tags, when stuff gets
- might slightly slow down "git log" (not much really)
- "git tag" which usually lists tags like releases, will list 50000+
viewing tags in GUI frontends may take serious time, as GUI frontends
seem not to expect this (tested with tortoise / tortoise revision graph
even crashes with that)
- may interfere otherwise when tagging releases etc / need to push new
tags individually by name.
Another approach would be to include such info in the commit-message.
But that has to be done with the commit. That is locally by each user.
(by a local git hook script).
Therefore those refs would not be unique. Duplicates are possible.
This is similar to the "git-svn-id" present in the commit message of all
On 13/02/2019 22:24, Martin Frb via lazarus wrote:
> I looked at a few ideas, if something like the svn numbers could be
Why would you want to shoehorn Git (a distributed version control
system) into the way SubVersion (a client/server based version control
They are fundamentally different. Yes Git can be used kind-of like a
client/server version control system, but then you loose pretty much all
the functionality that makes a distributed version control system so
Anyway, I'm not 100% sure what you want to achieve, but do you know the
It gives you a version-like result. A version (tag or branch name - tag
by default), number of commits since that 'major event' in the
repository history, and then the SHA1 of the actual commit you are on.
$ git describe
That output means the current HEAD commit is a descendant of "v1.4.1"
tag. It has 903 commits since the "v1.4.1" tag. The HEAD commit's SHA1
value is 6e8a7fbb. The "g" prefix is simply to say "git" was used.