From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jookia <166291@gmail.com> Subject: bug#22423: git-fetch does not update checked out tree when commit hash changes Date: Thu, 21 Jan 2016 22:50:02 +1100 Message-ID: <20160121115002.GA23171@novena-choice-citizen.lan> References: <20160121065403.GA4278@thebird.nl> <87twm79v05.fsf@gnu.org> <20160121090853.GA4914@thebird.nl> <87vb6n1bw9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMDoT-0002eY-QB for bug-guix@gnu.org; Thu, 21 Jan 2016 06:54:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMDoQ-0007NE-53 for bug-guix@gnu.org; Thu, 21 Jan 2016 06:54:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:39410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMDoQ-0007N4-2I for bug-guix@gnu.org; Thu, 21 Jan 2016 06:54:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aMDoP-0000lE-PD for bug-guix@gnu.org; Thu, 21 Jan 2016 06:54:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87vb6n1bw9.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 22423-done@debbugs.gnu.org On Thu, Jan 21, 2016 at 11:10:14AM +0100, Ludovic Courtès wrote: > Pjotr Prins 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.