On Thu, Dec 28, 2023 at 01:54:20AM +0100, Benjamin Stürz wrote:
> Hi,
> 
> first, thanks for creating got(1).
> I enjoy it more than git.
> 
> 
> I have written a small helper script called got-archive(1),
> for generating tarballs from a git repo,
> because I couldn't find another way to do so with just got(1).
> 
> You can use the attached port or goto
> https://got.stuerz.xyz/?action=summary&path=got-archive.git
> 
> I myself use it for populating my https://got.stuerz.xyz/download/
> If anyone cares, I'm open to submitting it to ports@openbsd.org.
> 
> Thanks,
> Benjamin Stürz

Your tool takes a simple approach and works fine as a wrapper
script. Still, it makes me wonder whether it would make sense
to integrate something like it into Got itself.

My hope would be that having built-in tooling for this use case
will encourage software maintainers to publish stable release
artifacts instead of relying on auto-generated release artifacts
such as those generated by Github.
Github's "release" artifacts are generated on the fly with
git-archive and cached for some time, but they will inevitably
change over time because git-archive's output for a given input
will eventually change after version upgrades. For example when
the behaviour of file compression tooling changes. This has been
an occasional pain to deal with in the OpenBSD ports tree.

In order to provide stable release tarballs for Got itself, we
currently use a Makefile target which performs the following steps:

 1. Run 'make clean' to ensure that no build artifacts are packaged.
 2. Ensure that the "-current" version number suffix gets dropped
    from the compiled-in version string.
 3. Build a list of files to package, and compare that to a known
    list of files. In case of any difference in packaged files,
    display the differences.
 4. Generate the archive.

This approach has been working for Got, and I have successfully adapted
this Makefile target for the NSH project. But there are some issues:

The approach is hidden in Got's Makefile and is not easy for users
to discover. As such, we leave it up to users (like yourself) to
devise some solution on their own. This in turn might push people
towards relying on auto-generating services such as Github's
release artifacts.

If the packaging list has changed, a useless tarball is left
behind in the work tree, and the file got-version.mk is left in
a modified state. Cleaning up the work tree before fixing things
and retrying is a manual step. With integration into Got this
could be handled in a more streamlined fashion.

Syncing the list of known files is a manual step and involves a
temporary copy of the file. A built-in command would be able to
display the diff and allow for packaging changes to be committed
or rejected automatically in a manner similar to 'got stage -p'
followed by 'got commit'.

Tools like autoconf produce unversioned files to be included in the
tarball and require a more complicated approach than your script
provides. Managing a list of files to package becomes unavoidable if
such projects would want to make use of this feature. One such project
is got-portable.