> You can write a script to do that and then commit the boilerplate> files.
So, I urge the user to run that script through my README?
Also, wouldn't that limit the user to using SourceHut for their
new repository?
>> You can write a script to do that and then commit the boilerplate>> files.>> So, I urge the user to run that script through my README?
See what would work best for you. One idea could be having a repository with a
sample script, invite users to clone your repository, configure this script and
then run it to configure their own repository on Sourcehut.
Something like this (not tested):
----------s---------s----------
#!/bin/bash
SRHT_USERNAME=~username
SRHT_REPO_NAME=repository_name
mkdir newproject && cd newproject
echo "# New project" > README.md
# create other files if you want
git init . && git add . && git commit -m init
git push git@git.sr.ht:$SRHT_USERNAME/$SRHT_REPO_NAME
git push -o description="Description of the repository" -o visibility=PUBLIC
echo DONE
----------e---------e----------
> Also, wouldn't that limit the user to using SourceHut for their> new repository?
Since Sourcehut does not support repository templates then, yes, such a script
would be an ad-hoc workaround just for Sourcehut (sorry maybe I didn't understand
your question)
Perhaps I don't fully understand the GH feature. To me this is a matter of
a git repository with a pruned main branch and/or links to release .tar.gz
downloads.
You could have a repo that you maintain and in the readme have a curl command
that will fetch the archive/release tarball from SourceHut. Something like:
curl -L https://git.sr.ht/~user/project/archive/release-tag.tar.gz |
gunzip | tar xv
cd project && git init
Devin,
That sounds like exactly what I needed! Thanks, you guys. Sorry for the
late response; I was figuring out why my replies were creating new threads.