[simpaticoder]

I loved this the moment I saw it. After looking at an example commit[1], I love it even more. The cursed knowledge entry is committed alongside the fix needed to address it. My first instinct is that every project should have a similar facility. The log is not just cathartic, but turns each frustrating speedbump into a positive learning experience. By making it public, it becomes both a tool for both commiseration and prevention.

1 - https://github.com/savely-krasovsky/immich/commit/aeb5368602...

[delusional]

I agree, I usually put this sort of information in the commit message itself. That way it's right there if anybody ever comes across the line and wonders "why did he write this terrible code, can't you just ___".

[motorest]

As a side note, it's becoming increasingly important to write down this info in places where LLMs can access it with the right context. Unfortunately commit history is not one of those spots.

[pushedx]

There's no reason that an LLM couldn't (or isn't) being trained on commit messages.

No difference between a git index and any other binary data (like video).

[motorest]

> There's no reason that an LLM couldn't (or isn't) being trained on commit messages.

You are arguing that it could. Hypotheticals.

But getting back to reality, today no coding assistant supports building system prompts from commit history. This means it doesn't. This is a statement of fact, not an hypothetical.

If you post context in commit messages, it is not used. If you dump a markdown file in the repo, it is used automaticaly.

What part are you having a hard time understanding?

[daveguy]

You seem to be confusing the construction of system prompts with "training". Prompts do not change a model's weights or train them in any way. Yes they influence output, but only in the same way different questions to LLMs (user prompts) influence output. Just because it's not available in current user interfaces to use commit messages as a prompt does not mean the model wasn't trained with them. It would be a huge failure for training from version controlled source code to not include the commit messages as part of the context. As that is a natural human language description of what a particular set of changes encompasses (given quality commits, but quality is a different issue).

[motorest]

> You seem to be confusing the construction of system prompts with "training".

I'm not. What part are you having a hard time following?

[mejutoco]

There are MCP Servers that give access to git repo information to any LLM supporting MCP Servers.

For example:

>The GitHub MCP Server connects AI tools directly to GitHub's platform. This gives AI agents, assistants, and chatbots the ability to read repositories and code files, manage issues and PRs, analyze code, and automate workflows. All through natural language interactions.

source: https://github.com/github/github-mcp-server

[laggyluke]

This is hair-splitting, because it's technically not a part of _system prompt_, but Claude Code can and does run `git log` even without being explicitly instructed to do so, today.

[freedomben]

Also there's a lot of humans that won't look at the commit history, and in many cases if the code has been moved around the commit history is deep and you have to traverse and read potentially quite a few commits. Nothing kills the motivation more than finally finding the original commit and it mentioning nothing of value. For some things it's worth the cost of looking, but it's ineffective often enough that many people won't bother

[simpaticoder]

The OP solved this problem by generating a well-known url, hosting it publicly, and including a link to the commit in the cursed knowledge inventory.

[gsmt]

I usually spot these kind of changes through git blame whenever I find a line suspicious and wonder why it was written like that

[rf15]

You are sadly completely missing the point of ever-self-improving automation. Just also use the commit history. Better yet: don't be a bot slave that is controlled and limited by their tools.

[motorest]

> You are sadly completely missing the point of ever-self-improving automation. Just also use the commit history.

I don't think you understand the issue you're commenting on.

It's irrelevant whether you can inject commit history in a prompt.

The whole point is that today's support for coding assistants does not support this source of data, whereas comments in source files and even README.md and markdown files in ./docs are supported out of the box.

If you rely on commit history to provide context to your team members, once they start using LLMs this context is completely ignored and omitted from any output. This means you've been providing context that's useles and doesn't have any impact on future changes.

If you actually want to help the project, you need to pay attention on whether your contributions are impactful. Dumping comments into what amounts to /dev/null has no impact whatsoever. Requiring your team to go way out of their way to include in each prompt extra context from a weird source that may or may not be relevant is a sure way to ensure no one uses it.

[rf15]

And my answer is: stop being a user when you want to be a developer so bad. Write the tool you need.

(we certainly did with our company internal tool, but then we're all seniors who only use autocomplete and query mechanisms other than the impractical chat concept)

[BobaFloutist]

That sounds like work someone should get paid to do.