sit

I want the opposite - tickets-as-code as part of the git repo. Something like SIT[1]. Fossil has it, but today's standard DVCS is git. There are 2 trends here: 1. Everything-as-a-code stored in the git repo in a text format close to the actual source code. If you store documention-as-a-code, diagrams-as-a-code, IaaC, tests-as-a-code, loadtesting-as-a-code, etc. - then why not issues/tickets as a code also? 2. Reduce number of tools/services/mechanisms you use in order to eliminate impedance mismatch, simplify workflows, and remove barriers to collaboration. For example if you standardize on Github, then you can use Guthub Issues, Projects, Packages, Actions, Codespaces, etc. And most developers are already having Github a/c. [1] https://github.com/sit-fyi/sit

I think the main problem with Git Lab and similar services is Git's inability to store anything other than code. If issues, wikis etc. would be stored in a Git repo itself, with the services potentially offering conveniences like web/email access etc. switching would be trivial. Git hosters would then need to be very, very careful and extremely competitive, as moving somewhere else would be a matter of minutes. There are some effords on this front[1], but I don't really know if anything will come of it. [1] https://github.com/sit-fyi/sit

Stumbled upon this similar project: https://github.com/sit-fyi/issue-tracking yesterday. I thought it was an interesting way of going about it. It's build upon this idea of serverless information tracking. https://github.com/sit-fyi/sit

About 1: take a look at sit https://github.com/sit-fyi/sit and git-dit https://github.com/neithernut/git-dit It would be nice to work with an existing project than roll your own.

SIT's issue tracking module stores merge requests (aka patches) in SIT itself, therefore, they can all be stored in a git repo. Case in point: https://github.com/sit-fyi/sit/commit/e9f96b84edc560bb1b0c0f... And this is how it looks in SIT: https://imgur.com/a/UCFmbsZ