bug#42420: git-fetch origins produce same store output when set recursive is set to true or false

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

Marius Bakke <marius@gnu.org> writes:

> pkill9 <pkill9@runbox.com> writes:
>
>> I built a source that uses git-fetch - by default (recursive? #f) - and
>> the package failed to build, then I remembered it uses submodules, so I
>> set (recursive? #t) but it failed with the same error. The problem is
>> that the store path of the source is the same for both, so it didn't
>> try to rebuild the git checkout with submodules checked out.
>>
>> After garbage collecting the source so it rebuilds it, I can build the
>> package.
>
> Could it be that you did not update the sha256 checksum of the package
> after setting (recursive? #t), so Guix thought it already had the
> complete checkout in the store?

Yes, that just happened to me.  It's confusing, but I don't see how we
can improve on that. pkill, next time this happens, you might want to
force a check on the cached source via 'guix build --source --check'.  I
believe this would flag the discrepancy.

Is there an action to do here, or should we simply close it?

Thanks,

Maxim