4 ms·

Going through security certification procedure, I was asked to list all the third party SAAS things we use. I didn't include github, gitlab, or anything else,

Going through security certification procedure, I was asked to list all the third party SAAS things we use. I didn't include github, gitlab, or anything else, because we don't use it. The auditor was going off on a tirade about how lack of version control is not okay at all, so convinced they were that 'no github or gitlab' must therefore mean 'no version control'. The mind boggles. He barely believed me when I showed how git just syncs with other git repos and that's really the start and end of it. This has actually gotten me into thinking about a few things. What a web site 'backed' by your git repo seems to get you is: * Some insights to those who don't have a full git dump. Mostly irrelevant. * CI stuff and hook processing, but this does not need to be done by the system that hosts git, or even a dedicated system in the first place. * An issue tracker that nicely links together and that auto-updates when you commit with messages like 'fixes #1234'. * Code signoff/review coordination. And all of that should be possible __with git__, no? If you have a policy that all code must be signed off otherwise it isn't allowed to be in the commit tree of your `main`, `deploy` or whatever you prefer to call it branch, then why not just say that a reviewer makes a commit that has no changes (git allows this with the right switches), _JUST_ a commit message that includes 'I vouch for this', signed by the reviewer? And that _IS_ the review? What if issue tickets are text files that show up in git, to close a ticket you make a commit that deletes it. Or even: Not text files at all, but branches where the commit messages forms the conversation about the issue, and the changes in the commits are what you're doing to address it (write a test case that reproduces the issue, then fix it, for example), and you close a ticket by removing the branch from that git repo that everybody uses as origin? Then all you really need is some lightweight read only web frontend so that the non-technically-savvy folks can observe progress on tickets in a nice web thingie perhaps, if that. But it's just a stateless web frontend that reads git commit trees and turns them into pretty HTML, really. Commit hooks to ensure policies such as 'at least 2 sign-off reviews needed before the CI server is supposed to deploy it to production'. Does something like that exist?

jacobr1 4y ago
maybe this? https://www.gerritcodereview.com/ https://www.gerritcodereview.com/
WorldMaker 4y ago
> If you have a policy that all code must be signed off otherwise it isn't allowed to be in the commit tree of your `main`, `deploy` or whatever you prefer to call it branch, then why not just say that a reviewer makes a commit that has no changes (git allows this with the right switches), _JUST_ a commit message that includes 'I vouch for this', signed by the reviewer? And that _IS_ the review? Git has two levels of built-in/native commit signing support. There's "Signed-Off-By" which adds a note to the bottom of a commit. Some projects use that for CLA verification. There's also GPG signing which signs a commit hash. If you want to use that as a level of "merge request"/"pull request" reviews there's a natural commit to sign that says you reviewed an entire branch: the merge commit itself. You can make a policy of --no-ff merges in your main and important branches. You can make a policy that they are signed (using one or both of the sign off types). You can make a policy that they are signed by someone who wasn't the author of most of the branch's commits. > What if issue tickets are text files that show up in git, to close a ticket you make a commit that deletes it. Or even: Not text files at all, but branches where the commit messages forms the conversation about the issue, and the changes in the commits are what you're doing to address it (write a test case that reproduces the issue, then fix it, for example), and you close a ticket by removing the branch from that git repo that everybody uses as origin? There's multiple cool approaches to this that people have tried. Search for "git distributed issue tracker" and you should find some of them. Some have okay web views. There's multiple options for storing the issues. Some use YAML files inside of the branch. The neat thing about files in the branch is that you can find things about where fixes happened using basic branch diffs. Some use git "Notes" which are indeed like git commits as a first class top-level object in git's object tree. Those do have the benefit that they form their own branches outside of your code branches. It's neat to explore what people have already tried in that area.

jacobr1 4y ago

maybe this? https://www.gerritcodereview.com/ https://www.gerritcodereview.com/

WorldMaker 4y ago

> If you have a policy that all code must be signed off otherwise it isn't allowed to be in the commit tree of your `main`, `deploy` or whatever you prefer to call it branch, then why not just say that a reviewer makes a commit that has no changes (git allows this with the right switches), _JUST_ a commit message that includes 'I vouch for this', signed by the reviewer? And that _IS_ the review? Git has two levels of built-in/native commit signing support. There's "Signed-Off-By" which adds a note to the bottom of a commit. Some projects use that for CLA verification. There's also GPG signing which signs a commit hash. If you want to use that as a level of "merge request"/"pull request" reviews there's a natural commit to sign that says you reviewed an entire branch: the merge commit itself. You can make a policy of --no-ff merges in your main and important branches. You can make a policy that they are signed (using one or both of the sign off types). You can make a policy that they are signed by someone who wasn't the author of most of the branch's commits. > What if issue tickets are text files that show up in git, to close a ticket you make a commit that deletes it. Or even: Not text files at all, but branches where the commit messages forms the conversation about the issue, and the changes in the commits are what you're doing to address it (write a test case that reproduces the issue, then fix it, for example), and you close a ticket by removing the branch from that git repo that everybody uses as origin? There's multiple cool approaches to this that people have tried. Search for "git distributed issue tracker" and you should find some of them. Some have okay web views. There's multiple options for storing the issues. Some use YAML files inside of the branch. The neat thing about files in the branch is that you can find things about where fixes happened using basic branch diffs. Some use git "Notes" which are indeed like git commits as a first class top-level object in git's object tree. Those do have the benefit that they form their own branches outside of your code branches. It's neat to explore what people have already tried in that area.