This is by design. It’s called a fixed-output derivation and it’s identified by its hash and not how it’s build. If you pass the same sha256 to two derivations Nix will think they are just two ways to build the same thing.
It’s like a ‘break’ in the build-time dependency tracking and hashing in that no matter how it’s built, as long as the specified hash is the same, they are considered identical. I think if you understand the existence of such breaks (which is necessary to establish trust in these network-going derivations), you can understand this: Take Nix’s perspective: Given two derivations X and Y with the same sha256, if I’ve already built X, then building Y is either going to
- Build something with
sha256identical to the output ofX, so why bother, or - Fail to complete or build something with the wrong
sha256, which means a build failure in general.
I agree that this is not the most intuitive behavior and can be difficult to communicate. See for example this StackOverflow question where the OP confused Git hash and output hash and considered it unacceptable to change the hash because a specific version is wanted.
So basically always take into account the sha256. Or rather, just think in terms of how Nix works.
I personally either just use nix-prefetch-git (or other related stuff) to get output hash for me and just treat it like any other argument when I fill it into a fetch*, or just simply change the sha256 not just as a sanity check but a deliberate action to make Nix tell me the hash.