That's the role of the commit title, with tags if you follow https://www.conventionalcommits.org/ standard.

99% of commit description will never be read. Only the title is usefull when you scroll to a git log.

But, for the remaining 1%, it means you ended up doing a git blame, git bisect or any funky stuff like this to troubleshot a bug. And when you find the commit that introduced the regression, written by some dude that leaved the company 5 years ago and see a description like "Add the whatever method in whatever class that do the stuff explained by the doc written in the file"... Well, thanks bro. But why did you do this ?!!!

A commit message is not supposed to be a summary of the code. It is supposed to gives information that you cannot deduct from the diff. Like:

• Is there an attached ticket ?
• Does it produce side effects ?
• Is it a quick and dirty fix just before the release ?
• What are the consequence of the modification ?
• Why you choose this approach instead of another ?
• Why are you not able to add regression test ? etc ...

The first guy at Cursor that create the feature to generate commit message from diff is just a fucking moron that don't understand the role of a commit message.

I'm still convince that polish notation was the biggest mistakes of Lisp. At some point, the guy who create Lisp language decide to get rid of 2 centuries of mathematic convention just because of a technical limitation that last for maybe 2 decades.

Oh, and no one to talked about (1- x) ?

I find it strange to explain how everything works but keep the implementation closed. It gives a "Trust me bro !" vibe, so I understand that some people might be reluctant about your project.

Anyway, using git as backend storage is cool. I love it when tools are repurposed for uses other than their original intent ^^.

Funny idea but... what's the point of showing a technical demo without the source code ? The added value of this idea relies on its implementation, not on its result.

Could be a comment indeed. It's hard, or even impossible, to clearly decide where to put an information. There are some guidelines, but no absolute rules. Commit messages, comments, API docs, tickets, wikis, etc... all of them serve different purpose.

• Comments are here to explain an implementation detail when code cannot be self-explanatory. They live as long as the code live (and are unfortunately not always updated). They are used when a developer arrives on that line of code.

• Commit message are here to explain why something has been added/removed. What happen before, what happen after, why this solution was needed. They are tightly couple to the diff and generally don't contain generic high-level information (unless commit is a design or architectural modification). They are used by the reviewer and 5 years later by someone that do a git blame to understand why this line was introduced and what happen if I remove it.

• API Docs explain the behavior of an API, as seen from the outside. They should not explain the implementation, nor explain in which case and which part of the system they are used.

• Tickets explain a user request. They detail who request this and for what purpose, but only from user point of view. No implementation detail.

• Wikis are here to cover your ass so you can say "See, it was written in the wiki !"

I'm really sad that after 20 year we still have to explain that commit message is not a summary of code modification.

Commit message is here to gives information's that are not visible in the diff. The context, the side effects, the decision that were made, etc... All of this cannot be generated by LLM.

Woops, forgot the link. I've fix it, thanks bro !

It works. You have hammers and nails. Then, someday, a dude come with the new Hammer23, with better ergonomical grip, colored high density 3 sided head, and so on. Yeah, cool, but I still have the same nails to nail, and my current hammer do the job perfectly. And I drilled a hole in my workbench ten year ago that have the perfect size for my current hammer.

Asking to cyptography experts. Would it be possible to flood a discussion with AI generated slope ? The discussion itslef would not be encrypted, but would be lost in millions of other generated discussion. A "private key" mechanism would be use to identify which message are part of your real discussion.

I suppose this would be compliant with Chat Control, as message are not encrypted. But without private key, you won't be able to identify which message are the good ones.

I wonder how many people get this ref nowadays.

Here is my "Tuesday evening 15min before leaving work analysis".

Before COVID, IT market was stable. After COVID, there was WAY too many IT offers. Then, market collapse supposedly because of AI:

(Source: https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)

In blue line, actual curve. In green line, what should have been IT market without COVID and AI.

For IT market to get back to equilibrium, red area should be equal to blue area. If I do some patchwork, I ended up with this:

So my conclusion is that it indeed slowly starting to recover and should be back to normal ~mid 2027.

Time to go home, bye 😁