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]