[ozim]

It is not coolest most unloved feature. It is a gimmick feature that could have been cool in some really specific cases like team of only developers running the whole company.

Whatever is needed goes into commit message and referencing tickets in separate system is a feature not a bug - because JIRA or any other system is used to communicate with non developers. Like business analysts don't get access to code or repositories at all for example or support people don't get access to the repositories and code.

Yeah I can see how one could write front end to get the notes visible/editable by non developers but it still does not make any sense because BA/Support others don't care about specific commits and a single feature might fit into a commit but most likely does not. Even more fun is when you have multi repo and your feature touches couple services then git notes are quite useless because then you really need reference to outside system.

[stopthe]

> business analysts don't get access to code or repositories at all for example or support people don't get access to the repositories and code.

Yes, but isn't it insane? What is the benefit from treating your own product as a black box? Yet that's mainstream. Sometimes I have the analyst (not on my team, but from a team we share a monorepo with) asking me questions that can be answered literally with a line of code. And she's a technical kind, knows SQL and such. And we write very idiomatic, high level code. But still, culture cannot change itself until it dies due to inherent inefficiency.

[ozim]

I think you underestimate inefficiency of requiring all business analysts and employees to learn GIT. If not all employees than more employees. I can pick put up job ad for BA saying knows JIRA and I have dozens of applicants.

We had a technical guy once where I worked that wanted to force sales guys to use LaTex to write documentation and requirements in and store it in GIT. I feel bad for the guy as he was laughed out by sales guys and he did not understood why because those are such a great tools…

[stopthe]

OTH the inefficiency of an analyst who cannot answer even basic questions about the current state of the product without developers' help. Distracting them, or even worse - blocking until a dev is available.

I think it boils down to the power of balance in the org. Likewise I've met developers who cannot book a meeting. Some people have privilege to choose what to learn and what to laugh at. Actually, I'm surprised your sales guys wrote any documentation at all:)

[chrishill89]

There’s plenty of data which is extra-commit (doesn’t belong in the commit messages but is relevant). Like if the tests passed[1], manual testing notes, iteration on code review, notes for code spelunking when you find a problematic 6+ month old commit.

[^1] https://news.ycombinator.com/item?id=44348438

[ozim]

Yeah but GIT notes are not the best tool for that unless you are single dev working on your project or you have team of only devs.

If you have manual testers they have their own set of tools and most of them don’t use or have working knowledge of GIT.

For code reviews everyone is using PRs and it is not because they don’t know about GIT notes but because no one is doing reviews per commit and there is no support for discussion and other tools that are baked in forges PR flows.

You can always use git notes for yourself but it is as I called it gimmick feature. I can make a bet you will use it for a week maybe couple weeks and then just stop because in description it sounds good but in practice - no one is using it.

[chrishill89]

> You can always use git notes for yourself but it is as I called it gimmick feature. I can make a bet you will use it for a week maybe couple weeks and then just stop because in description it sounds good but in practice - no one is using it.

I'll take that bet.