[debbugs-tracker] bug#22423: closed (git-fetch does not update checked out tree when commit hash changes)

[GNU bug Tracking System]

Your message dated Thu, 21 Jan 2016 09:50:18 +0100
with message-id <address@hidden>
and subject line Re: bug#22423: git-fetch does not update checked out tree when 
commit hash changes
has caused the debbugs.gnu.org bug report #22423,
regarding git-fetch does not update checked out tree when commit hash changes
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
22423: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22423
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> git-fetch does not update checked out tree when commit hash changes
>
>
>
>
> Date: 
>
> Thu, 21 Jan 2016 07:54:03 +0100
>
>
>
>
> User-agent: 
>
> Mutt/1.5.21 (2010-09-15)
>
>
>
>
> I can reliably reproduce this using a recent version of GNU Guix. 
>
> When updating the commit hash to a different commit the git-fetch
> derivation *does* change (I checked in guile), but the checked out git
> tree in the store does not change - it gets shared between the
> commits. I am not sure why the tree gets shared, but the effect is
> that the same package gets installed using the same
> /gnu/store/xxx-git-checkout.
>
> Removing the git-checkout dir and updating the Hash gives a missing
> dir error (as expected when they use the same).
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#22423: git-fetch does not update checked out tree when commit hash changes
>
>
>
>
> Date: 
>
> Thu, 21 Jan 2016 09:50:18 +0100
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
>
>
>
>
> Pjotr Prins <address@hidden> skribis:
>
> > When updating the commit hash to a different commit the git-fetch
> > derivation *does* change (I checked in guile), but the checked out git
> > tree in the store does not change - it gets shared between the
> > commits. I am not sure why the tree gets shared, but the effect is
> > that the same package gets installed using the same
> > /gnu/store/xxx-git-checkout.
>
> 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.
>
> Hope this clarifies things!
>
> Ludo’.
>
>
> --- End Message ---