Jookia <166...@gmail.com> skribis:
> 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 matt
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 HTT
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 specifi
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 y
Pjotr Prins 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
>
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
