fetchTree: Lix uses tag object hash instead of commit hash when ref points to a tag #1070

New issue

Open

opened 2025-12-08 18:30:56 +00:00 by goldstein · 1 comment

goldstein commented

2025-12-08 18:30:56 +00:00

Member

Describe the bug

When fetching git inputs with fetchTree, resulting source info contains rev pointing to the tree object instead of the commit object.

Steps To Reproduce

Evaluate

(builtins.fetchTree { type = "git"; url = "https://codeberg.org/goldstein/nix-tag-fetch-demo"; ref = "refs/tags/tag"; }).rev

The result is 047e5dffbba66b5eb0c1d8db04f661997fb825af, which is the tag object hash.

Expected behavior

7e6de55d9af75b3647c91f7e939107fcb3c8f196, which is the corresponding commit hash: https://codeberg.org/goldstein/nix-tag-fetch-demo/src/tag/tag. This is what CppNix does.

`nix --version` output

nix (Lix, like Nix) 2.95.0-pre20251128-dev_d5d03cd
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux, x86_64-v4-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/goldstein/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/goldstein/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/goldstein/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/goldstein/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/vqngvg0ljwb0zikxjh7h24akfbs82f0r-lix-2.95.0-pre20251128-dev_d5d03cd/share

Additional context

This is a divergence with CppNix. It might be intentional, but if so, I didn’t find info about it.

I do think returning commit hash here would be correct: flake docs say that returned rev is “the commit hash”.

## Describe the bug When fetching git inputs with `fetchTree`, resulting source info contains `rev` pointing to the tree object instead of the commit object. ## Steps To Reproduce Evaluate ```nix (builtins.fetchTree { type = "git"; url = "https://codeberg.org/goldstein/nix-tag-fetch-demo"; ref = "refs/tags/tag"; }).rev ``` The result is `047e5dffbba66b5eb0c1d8db04f661997fb825af`, which is the tag object hash. ## Expected behavior `7e6de55d9af75b3647c91f7e939107fcb3c8f196`, which is the corresponding commit hash: https://codeberg.org/goldstein/nix-tag-fetch-demo/src/tag/tag. This is what CppNix does. ## `nix --version` output ``` nix (Lix, like Nix) 2.95.0-pre20251128-dev_d5d03cd System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux, x86_64-v4-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/goldstein/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/goldstein/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/goldstein/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/goldstein/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/vqngvg0ljwb0zikxjh7h24akfbs82f0r-lix-2.95.0-pre20251128-dev_d5d03cd/share ``` ## Additional context This is a divergence with CppNix. It might be intentional, but if so, I didn’t find info about it. I do think returning commit hash here would be correct: [flake docs](https://docs.lix.systems/manual/lix/stable/command-ref/new-cli/nix3-flake.html#flake-format) say that returned rev is “the commit hash”.

goldstein added the

bug

label

2025-12-08 18:30:56 +00:00

commentatorforall added the

awaiting

contributors

Area/fetching

labels

2025-12-08 18:31:56 +00:00

pennae commented

2025-12-08 19:17:37 +00:00

Owner

yes, returning the commit hash rather than the tag hash seems like the much better behavior here. if the tag gets deleted the lockfile would cease to work even if the commit is still there, which is probably bad (and we've seen multiple projects pull and recreate tags, or just destroy them outright)