Re: use of git-fetch

[Ludovic Courtès]

Federico Beffa <address@hidden> skribis:

> On Wed, Jul 22, 2015 at 11:10 PM, Ludovic Courtès <address@hidden> wrote:
>> Federico Beffa <address@hidden> skribis:
>>
>>>               (sha256
>>>                (base32
>>>                 "06mc7kh3fzdh2mqkyynjnp0xpv30yfaiik8bqv8z5b6hldji3cky"))))
>>
>> [...]
>>
>>>               (sha256
>>>                (base32
>>>                 "06mc7kh3fzdh2mqkyynjnp0xpv30yfaiik8bqv8z5b6hldji3cky"))))
>>
>> Both recipes are telling that they use the same source.  So the daemon
>> cleverly saves one download since it already has the thing with that
>> hash on disk.  See?  :-)
>
> Thanks for the reply!
>
> I thought about this and, before posting, I also tried with an hash
> where the first character was changed from '0' to '6'. It gave the
> same result, even after deleting any existing 'emacs-dash' and
> 'emacs-s' derivation in the store. In my understanding that shouldn't
> happen. Is that correct?

Right, but we’d have to check the exact sequence of actions that you
took.

> By changing the hash to a totally different one (a string of '6's) it
> downloads the right repo. As expected, it complains about the hash and
> gives me the right one which I can copy into the package recipe.
> (That's The Lazy work-flow :-).)

Heh.  :-)

It’s a good idea to clone by hand though and check the signatures if
there are signed tags or commits (“trust on first clone”), but I’m
afraid this is not commonplace.

Ludo’.