Contributing new features from fork

Hello GOGS devs,

At the G-Node (g-node.org), we’ve been running GOGS for a couple of years now under the name GIN (https://gin.g-node.org) and it has been very successful. We greatly appreciate all the work that has gone into developing this service.

Since setting up and running GOGS, we’ve been maintaining our own fork for domain specific features, changes that we didn’t think would be needed or wanted in the upstream GOGS version. That said, there are some features that may turn out to be more generally desirable. More importantly, there are some features on our roadmap that align nicely with (or can make use of) features that are on the GOGS roadmap or wishlist (more API functionality comes to mind).

I didn’t want to open an Issue (or worse, a PR) on the GitHup repo before introducing myself and sharing some of the features to get some feedback on what kinds of things you might find useful. Most of these are minor and still require some work. Some require cleaning up from their initial implementations while others are implemented in separate files to keep our changes from interfering with upstream changes. In the latter case, if I were to send them upstream, I’d rewrite them in a way that fits the original GOGS code.

I would appreciate some feedback and thoughts.

  • Invite collaborators via email: We added the ability to send an invite to a user that’s not yet registered via email. The service creates a placeholder user and adds them as a collaborator and sends an email to a user that performs the same function as a password reset email. The new collaborator is asked to set their password when they accept the invite and are automatically given permissions on the repository.

  • Print a notice (banner) on every page from the contents of a file in the custom directory: On every page load, if a file exists in the custom directory called notice, the contents of the file are rendered as a system notice below the nav bar. This is meant for sending system notices for downtime or service interruptions without needing to change template code or restart the service.

  • Hidden, publicly accessible repositories: We added support for unlisted public repositories. These are publicly accessible repositories but don’t show up on a user’s public profile or in the Explore section.

There’s a few more bigger changes that I don’t think would be desirable for GOGS. We added support for git-annex, for binary data versioning, but this is a much bigger change that I think would require more discussion to send upstream to you. We also have a command line client that’s meant to simplify git and git-annex workflows by wrapping multiple calls from common workflows into simpler commands, which again isn’t very interesting for GOGS, but it does provide functionality that interacts with the GOGS API that’s missing from the gogs-client, so I could split those out and send them your way as well.

Thanks again for all the hard work and I hope you find any of the above useful.

Looking forward to working with you.