Conversation
If the reference for git+file is an annotated tag, the revision will
differ than when it's fetched using other fetchers such as `github:`
since Github seems to automatiacally peel to the underlying commit.
Turns out that rev-parse has the capability through it's syntax to
request the underlying commit by "peeling" using the `^{commit}` syntax.
This is safe to apply in all scenarios where the goal is to get an
underlying commit.
fixes NixOS#11266
github-actions
bot
added
the
fetching
github-actions
bot
added
the
with-tests
|
Is peeling the right behavior here? |
It is what GitHub is doing and the basis for the bug. Ultimately a tag is just a pointer to a commit so I do think that peeling is the right thing to do here.
|
In a local development workflow, shell-based CI, etc, you'd have a checkout that reports a commit being checked out, so most people/software will probably expect the commit id to appear, not a tag id. Also it seems that if we want to support not unpeeling, we'll have a much harder time for having to query the GitHub API even more. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2025-07-23-nix-team-meeting-minutes-236/67114/1 |
4 participants
If the reference for git+file is an annotated tag, the revision will differ than when it's fetched using other fetchers such as
github:since Github seems to automatiacally peel to the underlying commit.Turns out that rev-parse has the capability through it's syntax to request the underlying commit by "peeling" using the
^{commit}syntax.This is safe to apply in all scenarios where the goal is to get an underlying commit.
fixes #11266
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.