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

[Jonas Bernoulli <jonas@bernoul.li>]

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

> `elpaa--external-package-sync` won't actually fetch anything
> from the remote server and will just do `git merge` which will
> presumably do nothing at all unless you've `git fetched` something into
> `origin/externals/transient` since the last sync or you manually moved
> the `externals/transient` branch back to some earlier commit.

Now that you mention it, yes I did move back to some earlier commit.
I just tried with some new local-only commits and without rewinding
first and that indeed worked just fine.

I don't expect to rewind history going forward so this likely won't
cause me any issues anymore.  (I had to rewind because I had not yet
discarded the special "for-gnu-elpa" branch that moved the library to
the top-level.  In this case I did have to "rewrite history", but I
don't plan to do that again.)

> So, I think your diagnostic pointing at `elpaa--external-package-sync`
> was a red herring and the problem is rather that:
>
>>> `elpaa--make-one-package'
>>> is supposed to make packages from *commits*
>
> whereas you wanted to make a tarball from whatever was currently in
> `packages/transient`, including uncommitted changes.  Is that right?

No, I did in fact create a commit named "[WIP]".

> IOW the function that got in the way of your goal wasn't
> `elpaa--external-package-sync` but `elpaa--clean`.

Had I not created a commit, then yes, that would have been a problem,
but apparently I anticipated this complication. ;)

> I think the solution will be to make a new kind of make target which
> just builds one tarball and skips `elpaa--clean` (and will also skip
> `elpaa--external-package-sync` while we're at it).

Something like "make archive/<package>"
and "make archive-devel/<package>"?
That might be useful.

     Jonas