This PR should make this problem better (though it won’t handle the ‘rev
changed but url didn’t’ case) https://github.com/NixOS/nixpkgs/pull/5521
https://github.com/NixOS/nixpkgs/pull/5521
On Jan 1, 2015, at 1:27 PM, Shea Levy s...@shealevy.com wrote:
On Jan 1, 2015, at 1:22 PM, Bjørn
On Jan 1, 2015, at 1:22 PM, Bjørn Forsman bjorn.fors...@gmail.com wrote:
On 31 December 2014 at 17:50, Rico Huijbers rix0...@gmail.com wrote:
Hi,
When I copy/paste a fetchgit block from another file, and change the URL and
rev without changing the hash, I expect the download to fail
On 31 December 2014 at 17:50, Rico Huijbers rix0...@gmail.com wrote:
Hi,
When I copy/paste a fetchgit block from another file, and change the URL and
rev without changing the hash, I expect the download to fail (and tell me the
hash).
However, what actually happens is that fetchgit just
Hi,
When I copy/paste a fetchgit block from another file, and change the URL and
rev without changing the hash, I expect the download to fail (and tell me the
hash).
However, what actually happens is that fetchgit just looks at the hash, sees
that *something* with that hash has already been
Rico Huijbers rix0...@gmail.com napisał:
Hi,
(...)
Shouldn’t fetchgit build the hash from URL and rev, as opposed to the
provided hash? Or am I doing it wrong?
I think adding the rev to output hash is a good idea, but not the URL. URL can
change without changing fetchgit's output. (Well, rev
