Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
* Calculating major.minor.patch from commit hash
@ 2020-02-13 14:40 Martin Vejnár
  2020-02-13 14:46 ` Randall S. Becker
  0 siblings, 1 reply; 4+ messages in thread
From: Martin Vejnár @ 2020-02-13 14:40 UTC (permalink / raw)
  To: git

I'd like my releases to have major.minor.patch version number. While
increments of major.minor are something one has to do manually, I
don't want to do that for patch.

So I was thinking of having a VERSION file in the repo containing
major.minor and then calculate patch at the given commit C
automatically as the length of the longest path starting at C in the
subgraph containing only commits in which VERSION is the same as C's.

I can do that pretty easily right now by

* identifying commits in which VERSION changes with `git log --
VERSION` and then
* walking the graph in topo order with `git log --format=format:"%H %P"`.

The latter step can terminate early, so it doesn't have to walk the
entire repo, but the latter walks everything and can be quite slow.

Is there a more efficient way to do this?

If not, would there be an interest in a new builtin (git-depth?) that
would calculate the value?
-- 
Martin

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Calculating major.minor.patch from commit hash
  2020-02-13 14:40 Calculating major.minor.patch from commit hash Martin Vejnár
@ 2020-02-13 14:46 ` Randall S. Becker
  2020-02-13 14:54   ` Martin Vejnár
  0 siblings, 1 reply; 4+ messages in thread
From: Randall S. Becker @ 2020-02-13 14:46 UTC (permalink / raw)
  To: \'Martin Vejnár\, git

On February 13, 2020 9:41 AM, Martin Vejnár wrote:
> To: git@vger.kernel.org
> Subject: Calculating major.minor.patch from commit hash
> 
> I'd like my releases to have major.minor.patch version number. While
> increments of major.minor are something one has to do manually, I don't
> want to do that for patch.
> 
> So I was thinking of having a VERSION file in the repo containing major.minor
> and then calculate patch at the given commit C automatically as the length
> of the longest path starting at C in the subgraph containing only commits in
> which VERSION is the same as C's.
> 
> I can do that pretty easily right now by
> 
> * identifying commits in which VERSION changes with `git log -- VERSION`
> and then
> * walking the graph in topo order with `git log --format=format:"%H %P"`.
> 
> The latter step can terminate early, so it doesn't have to walk the entire
> repo, but the latter walks everything and can be quite slow.
> 
> Is there a more efficient way to do this?
> 
> If not, would there be an interest in a new builtin (git-depth?) that would
> calculate the value?

You should consider using annotated tags and the git describe command to derive your release number. We do this for all of our products and it works very well. For example:

$ git tag -a 1.6.4 commit-hash

Then, when building your release:

$ git describe --long --first-parent

Good luck,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Calculating major.minor.patch from commit hash
  2020-02-13 14:46 ` Randall S. Becker
@ 2020-02-13 14:54   ` Martin Vejnár
  2020-02-14  0:27     ` brian m. carlson
  0 siblings, 1 reply; 4+ messages in thread
From: Martin Vejnár @ 2020-02-13 14:54 UTC (permalink / raw)
  To: Randall S. Becker; +Cc: git

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Calculating major.minor.patch from commit hash
  2020-02-13 14:54   ` Martin Vejnár
@ 2020-02-14  0:27     ` brian m. carlson
  0 siblings, 0 replies; 4+ messages in thread
From: brian m. carlson @ 2020-02-14  0:27 UTC (permalink / raw)
  To: Martin Vejnár; +Cc: Randall S. Becker, git

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On 2020-02-13 at 14:54:48, Martin Vejnár wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-13 14:40 Calculating major.minor.patch from commit hash Martin Vejnár
2020-02-13 14:46 ` Randall S. Becker
2020-02-13 14:54   ` Martin Vejnár
2020-02-14  0:27     ` brian m. carlson

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git