Re: Calculating major.minor.patch from commit hash
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Feb 14, 2020, 00:27 UTC
- Message-ID
- <20200214002713.GA6806@camp.crustytoothpaste.net>
- In-Reply-To
- <CAJFfRmt3w60Yq+HS9oVmGtfPMzLeKzFSnkwS7v4_xe+eEWSxzw@mail.gmail.com>
On 2020-02-13 at 14:54:48, Martin Vejnár wrote:
Show 7 quoted lines
> On Thu, Feb 13, 2020 at 3:46 PM Randall S. Becker > <rsbecker@nexbridge.com> wrote: > > You should consider using annotated tags and the git describe command to derive your release number. [...] > > I'd like to avoid tags in this case, because a new tag/deletion of a > tag could change the hash->version mapping and I'd like that to be > stable.
Tags, usually signed tags, are the traditional way to indicate versions, and with them, git describe is usually used to describe commits. While it is possible to rewrite tags, people usually rely on convention and social sanction to not do that without good cause.
If that isn't enough for you, then you'll probably have to build things yourself. I'm not sure Git provides functionality that finds the longest path between two commits, but you can probably find the commit depth like the following:
git log --format="%H" -- VERSION | head -n1 | xargs -I{} git rev-list {}..HEAD | wc -l-- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204