maillists &mdash; csantosb https://infosec.press/csantosb/tag:maillists Random thoughts Wed, 13 May 2026 23:28:56 +0000 git forges https://infosec.press/csantosb/git-forges <![CDATA[img br/ Using #git is not the whole picture on #modernhw version control landscape. Git is great when one decides to locally follow changes, take diffs, create branches and so on. When it comes to collaboration with other people or to create a community around a common project, the need for extra tooling arises, and it becomes evident that git alone is not enough. A #gitforge fills this gap. !--more-- br/ Git bare repositories are a means of sharing the local git history remotely. Bares doesn’t show the worktree, as they are used solely as a common exchange place. This might be a remote server accessible through ssh, for example. Several different users may collaborate this way, provided they agree on a common workflow. Bares are more than enough for some needs. A front end on top of it may help to get an overview of what is going on and to take a look at branches, users and the like. All it takes to make this workflow useful is a little management, as git was designed with a fully distributed architecture in mind. Check the docs for more details. br/ Now, this approach is a bit too bare bones for most people. On top of bare git repositories, some decided to add extra functionality to ease using git remotely, calling for contributors attracted by buttons, colors, menus and most generally, being used to web frontends. Web forges include all usual suspects (project creation and configutation, markup rendering, user account and authorizations, project overview, etc.), as well as more advanced features (continuous integration, #ci, for testing and deployment with git hooks, wikis, code linters, built in actions, issue tracking, etc.). They abstract the use of git showing diffs, logs, issues threads, etc. As any other web gui tool, they come with its own set of inconvenients in what concern user freedom. br/ Popular examples are all around. #Gitlab may be deployed as a custom (not federated) instance, and is commonly found in research and public institutions; codeberg, based on forgejo, is a great example of how to deploy a lightweight #freesoftware instance of a collaborative forge (and the promise to federate on the fediverse). Many others exist, which more or less features, bells and whistles. You always have the choice. br/ sourcehut #Sourcehut, as a collaborative platform, deserves special attention. It departs from mainstream forges, following a different paradigm based on the most robust, distributed and flexible technology at our hands since decades, plain text #email. Git, since its origins, includes a close integration with email, as they both share a distributed philosophy, avoiding central point of failure silos (surprising how mosft git forges tend to concentrate in silos). Sourcehut core architecture is based on mail exchange, patches and #maillists, which turns out to be a much more flexible approach than that of what most forges propose. Their concept of project goes well beyond that of usual workflows, integrating nicely git with email, wikis, bug trackers and build features. They’re still in an alpha stage, so expect the best still to come. br/]]> img
Using #git is not the whole picture on #modernhw version control landscape. Git is great when one decides to locally follow changes, take diffs, create branches and so on. When it comes to collaboration with other people or to create a community around a common project, the need for extra tooling arises, and it becomes evident that git alone is not enough. A #gitforge fills this gap.
Git bare repositories are a means of sharing the local git history remotely. Bares doesn’t show the worktree, as they are used solely as a common exchange place. This might be a remote server accessible through ssh, for example. Several different users may collaborate this way, provided they agree on a common workflow. Bares are more than enough for some needs. A front end on top of it may help to get an overview of what is going on and to take a look at branches, users and the like. All it takes to make this workflow useful is a little management, as git was designed with a fully distributed architecture in mind. Check the docs for more details.
Now, this approach is a bit too bare bones for most people. On top of bare git repositories, some decided to add extra functionality to ease using git remotely, calling for contributors attracted by buttons, colors, menus and most generally, being used to web frontends. Web forges include all usual suspects (project creation and configutation, markup rendering, user account and authorizations, project overview, etc.), as well as more advanced features (continuous integration, #ci, for testing and deployment with git hooks, wikis, code linters, built in actions, issue tracking, etc.). They abstract the use of git showing diffs, logs, issues threads, etc. As any other web gui tool, they come with its own set of inconvenients in what concern user freedom.
Popular examples are all around. #Gitlab may be deployed as a custom (not federated) instance, and is commonly found in research and public institutions; codeberg, based on forgejo, is a great example of how to deploy a lightweight #freesoftware instance of a collaborative forge (and the promise to federate on the fediverse). Many others exist, which more or less features, bells and whistles. You always have the choice.

sourcehut

#Sourcehut, as a collaborative platform, deserves special attention. It departs from mainstream forges, following a different paradigm based on the most robust, distributed and flexible technology at our hands since decades, plain text #email. Git, since its origins, includes a close integration with email, as they both share a distributed philosophy, avoiding central point of failure silos (surprising how mosft git forges tend to concentrate in silos). Sourcehut core architecture is based on mail exchange, patches and #maillists, which turns out to be a much more flexible approach than that of what most forges propose. Their concept of project goes well beyond that of usual workflows, integrating nicely git with email, wikis, bug trackers and build features. They’re still in an alpha stage, so expect the best still to come.

]]> https://infosec.press/csantosb/git-forges Sun, 08 Dec 2024 22:36:11 +0000 sourcehut crash course https://infosec.press/csantosb/sourcehut-crash-course <![CDATA[img br/ Everything you need to get started with sourcehut, an original and interesting #gitforge . !--more-- br/ #Sourcehut is organized in independent, closely related services. #Git repositories, #maillists, #wiki pages, #bug trackers, etc. belong to different domains, see below. They cooperate to provide a pleasant and practical experience when doing #modernhw. br/ Check the official documentation for details in all that follows. br/ Each user is given a ~alias. Each user’s service will appear under the SERVICE.sr.ht/~user domain, and are accessible in the top panels of the web interface. br/ Main services are: br/ git git.sr.ht/~user/project, #git repositories. br/ There are no groups to combine them. I use dot notation to group my projects git.sr.ht/~user/group1.prj1. br/ builds builds.sr.ht/~user, task building service, with the list of builds by the user, with user’s recent activity. br/ builds.sr.ht, similar to the previous. br/ Builds are trigger by a .build.yml manifest, or by a .build folder folder with up to 4 manifest files, at the root of a project. br/ It is also possible to automatically submit builds when a patch to a repo with build manifests is sent to a mailing list. This is achieved by appending the project name as a prefix to the subject of the message, for example [PATCH project-name]. br/ Check doc for details. br/ hub The main tab, sourcehut, gives access to the hub hub.sr.ht/~user (identical to sr.ht/~user). br/ The hub displays user’s projects. br/ Projects are groups of git repositories, #maillists and bug trackers. There may be any of them in a project. br/ Sourcehut itself is organised as a project here https://sr.ht/~sircmpwn/sourcehut, and may be used as an example. br/ todo todo.sr.ht/~user, ticket tracking service, with the list of trackers created by the user, with user’s recent activity br/ todo.sr.ht, similar to the previous br/ man man.sr.ht/~user/NAME, #wiki service to create documentation, with the wikis created by the user br/ man.sr.ht, sourcehut documentation br/ man.sr.ht/builds.sr.ht, builds service documentation br/ man.sr.ht/hub.sr.ht, hub service documentation, etc. br/ lists lists.sr.ht/~user/NAME, #email #maillists service, with the list created by the user, with user’s recent activity br/ lists.sr.ht, lists the user follows, with recent activity br/ Extra services are alse provided: br/ chat chat.sr.ht, without the user alias, is a paid service. It provides a bouncer to save history of IRC channels while not connected, and may be used from another IRC client. br/ paste.sr.ht Paste hosting service. br/ srht.site Once again, the official documentation gives in depth details about the previous. And remember, there is also hut to operate from the #cli. br/]]> img
Everything you need to get started with sourcehut, an original and interesting #gitforge .
#Sourcehut is organized in independent, closely related services. #Git repositories, #maillists, #wiki pages, #bug trackers, etc. belong to different domains, see below. They cooperate to provide a pleasant and practical experience when doing #modernhw.
Check the official documentation for details in all that follows.
Each user is given a ~alias. Each user’s service will appear under the SERVICE.sr.ht/~user domain, and are accessible in the top panels of the web interface.
Main services are:

git

git.sr.ht/~user/project, #git repositories.
There are no groups to combine them. I use dot notation to group my projects git.sr.ht/~user/group1.prj1.

builds

builds.sr.ht/~user, task building service, with the list of builds by the user, with user’s recent activity.
builds.sr.ht, similar to the previous.
Builds are trigger by a .build.yml manifest, or by a .build folder folder with up to 4 manifest files, at the root of a project.
It is also possible to automatically submit builds when a patch to a repo with build manifests is sent to a mailing list. This is achieved by appending the project name as a prefix to the subject of the message, for example [PATCH project-name].
Check doc for details.

hub

The main tab, sourcehut, gives access to the hub hub.sr.ht/~user (identical to sr.ht/~user).
The hub displays user’s projects.
Projects are groups of git repositories, #maillists and bug trackers. There may be any of them in a project.
Sourcehut itself is organised as a project here https://sr.ht/~sircmpwn/sourcehut, and may be used as an example.

todo

todo.sr.ht/~user, ticket tracking service, with the list of trackers created by the user, with user’s recent activity
todo.sr.ht, similar to the previous

man

man.sr.ht/~user/NAME, #wiki service to create documentation, with the wikis created by the user
man.sr.ht, sourcehut documentation
man.sr.ht/builds.sr.ht, builds service documentation
man.sr.ht/hub.sr.ht, hub service documentation, etc.

lists

lists.sr.ht/~user/NAME, #email #maillists service, with the list created by the user, with user’s recent activity
lists.sr.ht, lists the user follows, with recent activity

Extra services are alse provided:

chat

chat.sr.ht, without the user alias, is a paid service. It provides a bouncer to save history of IRC channels while not connected, and may be used from another IRC client.

paste.sr.ht

Paste hosting service.

srht.site

Once again, the official documentation gives in depth details about the previous. And remember, there is also hut to operate from the #cli.

]]> https://infosec.press/csantosb/sourcehut-crash-course Fri, 29 Nov 2024 14:33:48 +0000