bug#45345: [elpa-archive] "make build/<package>" should not pull unconditionally

[Jonas Bernoulli <jonas@bernoul.li>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> - Another advantage is that the new code makes it much easier to build
>>>   your own tarballs, for example to test them before pushing to code.
>>>   You can just do `make build/[PKGNAME]` and the resulting package will
>>>   be built in `archive/[PKGNAME]-[VERSION].tar.
>> That almost worked. "make build/<package>" (or `elpaa--make-one-package')
>> calls `elpaa--external-package-sync', which pulls.  That of course is not
>> desirable when one wants to test some other revision of the package than
>> what would end up being pulled.
>
> Could you give some detail about the situation in which doing `git pull`
> was a problem for you?

I was making some experimental changes.  In this case the changes where
to transient's internal tools responsible for updating version numbers
in the manual.  These tools are broken when used in a worktree of the
elpa repository because they relay in git tags, which do not exist here.

I did not want to push any of these very temporary experiments to the
public transient repository, just so elpa-archive could pull them from
there.

IMO its irrelevant what experiments I was running.  There will always
be things people will want to try out before making them public.

> I mean, obviously I could just move that call to
> `elpaa--external-package-sync` elsewhere, but `elpaa--make-one-package'
> is supposed to make packages from *commits* (it normally makes two
> packages, one from the head of the branch and another from the last
> commit that changed `Version:` line) so it "inherently" moves between
> different commits.

I dealt with that by creating a temporary dummy commit.  I also bumped
the Package-Version to some temporary fantasy number in that same
commit.  None of that I want to push to some public location just so I
can test locally.

     Jonas