bug#22423: git-fetch does not update checked out tree when commit hash changes

[Jookia <166291@gmail.com>]

On Thu, Jan 21, 2016 at 11:10:14AM +0100, Ludovic Courtès wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
> 
> > On Thu, Jan 21, 2016 at 09:50:18AM +0100, Ludovic Courtès wrote:
> >> This is expected: origins are fixed-output derivations, meaning that it
> >> does not matter how we perform them (using Git, over HTTP, or thanks to
> >> an avian carrier), as long as the result has the specified sha256.
> >> 
> >> Thus, when you change, say, the Git commit ID or origin ‘method’ without
> >> changing the ‘sha256’ field, nothing happens: the daemon says “OK, I
> >> already have a store item with that ‘sha256’, so I don’t do anything.”
> >> 
> >> Clearly, one has to be cautious with this, it’s easy to mistakenly use
> >> the old source.
> >
> > Hmmm. I thought the sha256 was calculated over the derivation +
> > sources
> 
> What you’re saying is true of the hash that appears in /gnu/store file
> name, but I was referring to the ‘sha256’ field of origins, which is a
> different thing.
> 
> Ludo’.

I think this is a bit of a problem even if it's expected: Often times we can't
calculate the hash until it's downloaded and get a hash mismatch. The other day
I rebuilt NixOS almost entirely on my machine and changed the revision on
Firefox to a new branch but didn't change the hash since I expected a mismatch.

Needles to say I realized what happened when I checked Firefox's version. I
think it'd be great to have a 'INVALID' hash we can use for development that
just prints a mismatch and errors out like usual. Maybe this is possible in
Guix, but it didn't seem documented and it's not possible in NixOS.

Cheers,
Jookia.