I wonder if instead of checking the prompts into the repo as files, a better idea would be to store them inside the commit messages.

If prompts are specifications for a change of the system's behavior, then it seems natural to manage them as changes and not as resources.

This would also keep them in the right "historical context" of the repo and avoid the "prompt rot" you were talking about.

▲ aDyslecticCrow a day ago | parent | next [-]

Git history is a bit annoying to navigate, but that may just be a tooling issue. I've long been bothered by the loss of the review history when merging a PR. Would actually be pretty cool to click on a row of code and see the commit messages that formed that row of code in a little sidebar, and the technical discussions that were behind it.

Functional safety development processes often demand code-review, technical design decisions, changes of plans, or intentional compromises; to be linked together with reference IDs in the code they effect. But the workflow for this is usually extremely manual and absolute misery. But a codebase made like this is like magic to read later.

▲ ffsm8 a day ago | parent | next [-]

Gits data structure already allows for that, as you can add additional data to a commit after it was made.

You'd consequently only need to implement your custom git gui and extension to visualize this information.

Maybe a good project for the next weekend? Just eg make a prototype tui in golang and see where you end up

	▲	jamietanna 20 hours ago \| parent [-]
		I've definitely seen at least one tool in the past - maybe via simonw - to use `git notes` to track that

▲ michaelmure 20 hours ago | parent | prev | next [-]

I want to do something like that with git-bug (keeping track of prompt/conversation/review alongside normal commit), but unsure what the DX would be. Insights welcome :)

▲ chapterjason 20 hours ago | parent | prev | next [-]

You literally described git blame usage in almost every editor which supports git properly.

▲ aDyslecticCrow 11 hours ago | parent | next [-]

Yes and no. Git blame is great yes, but it's still rather crude. If three commits changed one condition; it only shows the top commit. Getting a full sense of the history of a function over time is far less ergonomic.

The tech and data-structure is there; but the common UX is not quite expressing the data in a sophisticated manner. It doesn't help that the default diff algorithm is rather crude as-well.

▲ mschuster91 18 hours ago | parent | prev [-]

git blame falls apart on someone running a new linter config across the project or doing some refactoring work.

	▲	bulatb 13 hours ago \| parent \| next [-]
		Some tools will automatically ignore commits in a .git-blame-ignore-revs file. Git itself can "blame --ignore-rev <hash>" or "blame --ignore-revs-file <file>" since version 2.23. `git commit -m "Autoformat source files" git log --format="# %s%n%H" -1 >> .git-blame-ignore-revs git add .git-blame-ignore-revs git commit -m "Ignore autoformat commit in blames" cat .git-blame-ignore-revs # Autoformat source files 0a1b2c3d... git blame --ignore-revs-file .git-blame-ignore-revs code.src` Git can use it automatically too: `git config blame.ignoreRevsFile .git-blame-ignore-revs git blame code.src` Though git-blame may fail or crash if blame.ignoreRevsFile is set but the file is missing (hence "config", not "config --global"). Since version 2.53, a configured ignoreRevsFile can be missing if the value starts with ":(optional)".
	▲	14 hours ago \| parent \| prev \| next [-]
		[deleted]
	▲	matijsvzuijlen 16 hours ago \| parent \| prev [-]
		In GitHub and vim at least you can dig past those commits to see earlier relevant commits. I'm sure there are more tools that allow this.

▲ a day ago | parent | prev [-]

[deleted]

▲ boomlinde 11 hours ago | parent | prev [-]

I am skeptical of adding anything but a brief description of the change, the reason for the change and possibly some explanation of non-obvious implementation choices to the commit message.

The reason is that the commit message log serves as an overview of the changes commited. That's what humans use it for, anyway: to get an idea of what happened since they last pulled, to help give an idea of where a regression might have been introduced and so on, at a glance. To that end, brevity is very useful.

My understanding is that chatbots used to perform such tasks will also benefit from brevity.

▲

xg15 10 hours ago | parent [-]

Well, at least in Git, the commit message already has two sections.

AFAIK, the first line is supposed to be the a very brief summary, while the other lines may contain additional information and can sometimes make up a pretty long text. Lots of tools make use of this convention and only show the first line if no detail information is needed.

Most tools that show the history only show the first line of each commit.

But I agree with you, this still assumes that long commit messages are rare and not that almost every commit has a huge message. Also, "long" doesn't mean you should put a novel in there.

	▲	boomlinde 6 hours ago \| parent [-]
		I think long is fine if that's necessary to get a rough idea of what the change is about across. Discerning in the choice of what information to include is perhaps a better way to put it. In those terms we should consider how likely it is for prompts to be immediately useful information when browsing the commit history, and whether it can't instead be reduced to an informative summary. As far as specifications for changes go, the diff itself is as good a spec as it gets. It unambiguously describes the exact change that was made. The prompt you give a chatbot to make that change is IMO something else. Maybe it's more fair to call that a specification of the work you wanted it to perform.