`git describe` is quite a bit less powerful, unfortunately. First, while the string coming from `git-describe` can be used in git commands, that’s only because it contains the abbreviated commit hash, which alone is sufficient to identify a commit. Second, such identifiers end up being pretty weird on the default branch since we often use tags to mark branch points. This means that commits on the default branch would reset their count every time we branched.
Jonathan > On Oct 4, 2020, at 2:41 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 02.10.2020, 19:46, "Jonathan Bedard" <jbed...@apple.com>: >> Monotonic Commit Identifiers >> Of great interest to Apple’s engineers has been retaining some kind of >> ordered tag we can use to refer to commits to make defending CI and >> bisection easier. We’ve developed a scheme for this that assigns commits an >> ordered identifier per-branch, outlined in >> https://trac.webkit.org/wiki/commit-identifiers, designed to be used >> alongside git hashes. These identifiers can be used in our current >> Subversion repository, and we would like to start using them before the >> project has transitions to git. > > AFAIU, this is very close to what `git describe` does: you give it git hash, > it gives you new identifier consisting of 3 parts: > > <closest git tag>-<number of commits since that tag>-<abbreviated commit hash> > > Note that resulting identifier can be used in all git operations which > require git reference (like `git log` or `git show`). > So, if you push git tags to main repository (maybe lightweight tags, if you > are planning to have lots of them), there is no need to invent any other > identifiers. > > As for bisection, git bisect works just fine when given two commit hashes. > > > -- > Regards, > Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
