[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45345: [elpa-archive] "make build/<package>" should not pull uncondi
From: |
Stefan Monnier |
Subject: |
bug#45345: [elpa-archive] "make build/<package>" should not pull unconditionally |
Date: |
Mon, 21 Dec 2020 09:33:20 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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.
There's definitely no need to affect remote repositories.
Assuming you're using the "normal" setup where `packages/transient` is
a worktree, `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.
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?
IOW the function that got in the way of your goal wasn't
`elpaa--external-package-sync` but `elpaa--clean`.
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).
Stefan