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
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
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.
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.
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