nix icon indicating copy to clipboard operation
nix copied to clipboard

Different commit id used when using local vs remote tag reference

Open dpc opened this issue 1 year ago • 3 comments

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.

dpc avatar Aug 07 '24 18:08 dpc

As a workaround I can just use rev=$(git rev-parse ${tag}^{commit}) to always point at the commit it in all invocations.

dpc avatar Aug 07 '24 19:08 dpc

Git fetching has been revised significantly since 2.18. Could you try with 2.24?

roberth avatar Aug 11 '24 20:08 roberth

AFAICT, still happens with nix_2_23

dpc avatar Aug 26 '24 23:08 dpc

@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

fzakaria avatar Jul 22 '25 03:07 fzakaria

Fix is up!

fzakaria avatar Jul 22 '25 05:07 fzakaria