You can do that with git-appraise: https://github.com/google/git-appraise

Fossil (https://fossil-scm.org/) seems to align with your ideals.

Can someone elaborate or attach relevant links? I'm extremely interested.

The idea that Fossil has as an SCM is that all your workflow ought to belong in the source repository; so, for example, the issue tracker that comes with Fossil stores all of its data inside of the same repo as the code. If you work on an issue and update it, the update travels with the code commits. If you raise an issue and push it to an upstream repo, everyone who syncs against it will see the issue, and so on and so forth.

Relevant discussion: https://www.reddit.com/r/linux/comments/914z8v/comment/e2yib...

I do find the homepage very complete and the documentation very understandable though, would recomend taking a look if you're interested.

You could do them as git notes, which gives you a non-vendor specific mechanism for handling this kind of data in git. However, you do need to make a point about having changes to notes get pushed to version control, so it does require either a tool or onboarding to become useful for what you’re talking about.

Git can store a variety of other objects in the repo as well, but the built in git-notes mechanism springs most immediately to my mind as the thing you’re looking for.

GitHub used to have some support for notes, they should bring that back: https://github.blog/2010-08-25-git-notes-display/

Comments can be made specific to a code line. Git notes are attached to a SHA-1. So you would first need some standard how to refer to lines or nobody else can read your comments.

What about commiting those comments directly into source files as comments with some tag? Like `// REVIEW looks like a bug`?

Actually I think that lots of things that's currently located outside of the repo should be in the repo. Like issues: just put them into some `issues` directory with some standard format and build UI around it.

That's basically what Fossil does. You get to do distributed issue tracking and wiki using it, it also has some advantages when it comes to subprojects compared to git submodules.

I like that idea and have tried that approach. Unfortunately, there needs to be tooling that can more easily parse a repository for those and make them part of the flow. Simply grepping isn't really a great way to do that.

That’s called a mailing list, and it’s supported by Git, no?

That is an ungoogleable concept so unless it’s front and center in the docs or posted here every six months, nobody is going to know what you’re talking about.

Do you mean attaching a mailing list to git or a feature for syncing comments to commit ids? If the former, you think sending a new guy to read four years of yammering about code is a useful or non hostile suggestion? It’s okay to be a misanthrope, as long as you understand that about yourself and when it colors your interactions.

But this is how this conversation usually goes:

There are any number of addons and special hidden features of git. If they don’t propagate to and from developer machines without proper user configuration, it’s a checkbox feature, not a real one. And the worst kind - the ones where people can dismiss a real and near universal problem by saying “we have X at home”.

Half of the good features of version control, CI/CD, you name it, are good in part because they only require one or two people to put in the effort and then everyone benefits, whether they recognize the value in it immediately, over time, or leave the team insisting it never helped them once even though other people know that’s not true.

Any feature that requires everyone to set it up on their box requires unanimous decision. That doesn’t scale, and it barely works on a small fixed team either.

Most of the tools I see people claim git has involve changing the configs or your behavior in order to sync the extra metadata. Do it by default or don’t do it at all. This is you being wishy washy and letting someone else take the blame for it not being used.

Edit: are you talking about ‘git am?’ That has nothing at all to do with what I’m talking about and also is only used on non commercial products. The only people I know of who use this at work are professional OSS committers who aren’t working on projects hosted on GitHub. Which is zero people actually in my professional circle, and if those people know anyone they haven’t mentioned it where I’ve heard it.

Yes, I'm talking about "git send-mail" and "git am". Actually, it's relevant to what you're already saying. You can have an e-mail list based code review process, and store it in your on-premise servers, or in your infrastructure for what matters.

You can argue about the utility and practicality of GitHub, and the tools provided by the platform, however Git is neither is an invention of GitHub nor have a monopoly over it.

Lastly, having no clue about a technology as a professional developer has nothing to do with the utility or usefulness of the feature. On the contrary, a professional developer should be able to work in a much more flexible and open-minded manner about different working methods and workflows.

All in all, the mailing list can act as an internal time-based knowledge base which can store both the code review and decisions coming out of it. The decision to use it or not of course yours and your team's, but send-email and am are not features confined to "professional OSS committers who aren't working on projects hosted on GitHub" by any means technical and social.

Also, you can like the feature or not, and may decide against it just on personal preferences. However, this neither moves the feature to a niche place, or makes it obsolete.

The mailing list does not tie directly to a line of code. That’s the point of tracking commentary with the code. It helps keep a rough level of confidence about what comments are still relevant (based on whether or how much of the code survived).

Email allows inline git reviews and comments, without HTML, CSS, JS, and the microservice jungle needed to host a web app these days.

I follow a few of the Linux kernel mailing lists and frankly I am jealous af; no Slack, no Jira, no web UI I can accidentally refresh which flushes state and deletes the comment I was writing. Was less bandwidth hungry.

Hosted UI just seem like a huge waste and a whole lot of agency capture by VCs. Just release a Docker image, give me an API key.

Same here. I've tried though for some time to get more into the Linux Kernel workflow of git and struggle to this day. I think it is great for people that have spend the time to incorporate the built-in tooling, but a lot of people simply never because it is time consuming and opinionated. The biggest hurdle is probably just having a text-based mail client and SMTP setup.