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).
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.