Why is the r-ryantm bot using `refs/tags` in the version?

For example: https://github.com/NixOS/nixpkgs/pull/182404/files

Is there a new policy to set rev to refs/tags/${version} when using fetchFromGitHub?

$ rg 'rev = "refs/tags' | wc -l
     379
1 Like

https://github.com/NixOS/nixpkgs/commit/7f5915b04801f383a3504a011601e2fb09dfedf8

1 Like

I was getting tired of github saying that it couldn’t find a unique reference by a given rev. So I did that.

Is it necessary to use refs/tags? In some cases. Does it avoid a lot of pain with automated updates? yes.

3 Likes

Why wouldn’t the reference be unique, though? I can’t say that I’ve ever run into this issue with fetchFromGitHub before – do you mind explaining a bit?

If I make a branch v1.2.3, and then also tag a release v1.2.3, what is git supposed to do when you ask for v1.2.3 and they reference different commits?

Currently, git just throws it’s arms up and says “there’s not a unique thing by this name, sorry I can’t give you what you want”.

This was beginning to happen 2-10 times each python-updates round.

2 Likes

Makes sense – maybe we could add this to the fetchers? Something like tag, where that checks out refs/tags/${tag}, for consistency.

maybe, but we already have ref and rev which in addition to tag would further complicate the “weirdness” budget of fetchFromGitHub. This is also in addition the current weirdness budget that already exists

2 Likes