bug#43893: [PATCH] maint: update-guix-package: Ensure sources are clean.

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

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Maxim,
>
> hmm, git worktree can fail if the commit already is checked out somewhere (for
> example if you invoke make update-guix-package twice in a row), or if the user
> used git worktree on that repo for that commit for other purposes.  That would
> mean that
>
>   make update-guix-package

The "--detached" option is the one allowing to have multiple checkouts of
the same commit.

> would fail in weird undocumented ways again.  Please please let's document
> stuff at least.
>
> Also, why not just fail when there's uncommitted stuff?

Well, if the tool says clearly it's going to update the guix package to
commit X, which is the latest commit in your tree, and doesn't have
technical reasons preventing it from doing so successfully, why enforce
a clean tree?

Using a worktree to setup a pristine checkout also covers for uses such
as 'git update-index --skip-worktree some-file-or-path' or 'git
update-index --assume-unchanged some-file-or-path', which would go
undetected by checking for modifications with 'git diff-index --quiet
HEAD'.  We'd also have to check for the output of

> This patch looks like it goes to quite some length to enable you to build a
> guix package of committed stuff only (which is NOT what your working copy is
> actually like).  Is there a use case for that?  Sounds weird to me.

That's exactly what the tool should do, as there's no point upgrading
the guix package definition to a state that doesn't exist as a commit.

> Even if there's a use case for that, please add a warning if there are
> uncommitted changes that are now not included in the "guix" package.

They were never included in the upgraded guix package (the one you'd
'git push' anyway), they were just put in your store for computing the
hash, which is problematic as we saw.

> Other than that, okay.
>
>>#FIXME: This doesn't work (recursion?)
>>./pre-inst-env guix build guix --with-git-url=guix=file://$PWD
>
> Why doesn't it work?  That sounds like a big limitation--that basically means
> you can't test with local-only commits, you'd always have to push.  We
> should find out why this doesn't work and fix it.

I've tested it again, and it worked... I think what got is surprising is
that the only output I had for multiple minutes was:

--8<---------------cut here---------------start------------->8---
updating checkout of 'file:///home/maxim/src/guix'...
--8<---------------cut here---------------end--------------->8---

And the CPU peaked and the RAM stayed around 1 GiB while it was doing
its magic.

Maxim