Different commit id used when using local vs remote tag reference
Describe the bug
We are trying to rely on Nix deterministic building and I found some weird behavior.
when building using local git+file: vs remote github to the same tag reference, we see different results.
nix build "git+file:$(pwd)?ref=refs/tags/v0.4.0#fedimintd" && sha256sum result/bin/fedimintd
0eed8de41a7243e66201fc29b1a66a92095bf672002be4025bb507aae9172301 result/bin/fedimintd
and
nix build 'github:fedimint/fedimint?ref=refs/tags/v0.4.0#fedimintd' && sha256sum result/bin/fedimintd
2ac5afee3e642f012efff407a903487dd69aabc6bf356128693753693ef4b314 result/bin/fedimintd
This is because we embedd the the git tag passed by the Nix/flake into our binary, as a post processing step. I investigated the diff between binaries and indeed it seems that in the local invocation Nix will pass the object id of the annotated tag itself vs object id of the commit that the tag points at. Both IDs resolve to the same commit ID:
> g rev-parse 6627a75b23a9ce1f^{commit}
d0877d0310453b737309cef404d98300f3dfa0d2
> g rev-parse d0877d0310453b73^{commit}
d0877d0310453b737309cef404d98300f3dfa0d2
However after trying to use rev= version of the commit itself in both invocations to compare the results:
> nix build 'github:fedimint/fedimint?rev=d0877d0310453b737309cef404d98300f3dfa0d2#fedimintd' && sha256sum result/bin/fedimintd
2ac5afee3e642f012efff407a903487dd69aabc6bf356128693753693ef4b314 result/bin/fedimintd
> nix build 'github:fedimint/fedimint?rev=d0877d0310453b737309cef404d98300f3dfa0d2#fedimintd' && sha256sum result/bin/fedimintd
2ac5afee3e642f012efff407a903487dd69aabc6bf356128693753693ef4b314 result/bin/fedimintd
now all the invocations (even one that had a weird behavior before) are giving the same (2ac5afee3e) result, so it looks like something about the caching kicked in and bandaided the issue.
Expected behavior
I guess Nix should peel of the tag -> commit indirection to make all invocations use the same git rev.
nix-env --version output
- 2.18.5
- 2.23.?
Additional context na
Priorities
Add :+1: to issues you find important.
As a workaround I can just use rev=$(git rev-parse ${tag}^{commit}) to always point at the commit it in all invocations.
Git fetching has been revised significantly since 2.18. Could you try with 2.24?
AFAICT, still happens with nix_2_23
@roberth I built a much smaller reproduction to investigate: https://github.com/fzakaria/reproductions/tree/nix/issue-11266
It's simple
packages = forAllSystems (system: {
default = nixpkgsFor.${system}.writeText "tag-embedded" ''
${self.rev or self.dirtyRev or "dirty"}
'';
});
Here is the commit 322b1878ac946505c2cfcbd65295eacbd55bb0c2
git log --oneline --no-abbrev
322b1878ac946505c2cfcbd65295eacbd55bb0c2 (HEAD -> nix/issue-11266, tag: lightweight-tag, tag: annotated-tag, origin/nix/issue-11266) Commit with file that contains commit
I now create an annotated tag at the commit and try it from the two methods listed.
Wrong
> nix build "git+file:/home/fmzakari/code/github.com/fzakaria/reproductions?ref=refs/tags/annotated-tag" && sha256sum result
0c337465904a0f8838f5843263a429365f71e187a848575215e77afc563ffb57 result
> cat result
596a14ad88d779861a25ac502e3eb02e9e26a3da
it is in fact including the annotated tag commit like @dpc mentioned.
> git show-ref --tags
596a14ad88d779861a25ac502e3eb02e9e26a3da refs/tags/annotated-tag
Good
> nix build 'github:fzakaria/reproductions?ref=refs/tags/annotated-tag' && sha256sum result
b8744ecb72887aba2f896d906b1b30ee1d8365b9423bca01bc137adc8ee0f708 result
> cat result
322b1878ac946505c2cfcbd65295eacbd55bb0c2
Fix is up!