"Bug uncovered" doesn't mean "bug fixed."

Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions.

At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't even be able to download and build Wine 9.21 staging, when yabridge worked.

Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends.

(I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.)

I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.

Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality.

A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.

Diagnosing why a bug happened is interesting. Sometimes it points to a communication shortcoming that the project/organization should strive to improve on. Of course, if you're slinging code with a few buddies, it might not matter.

In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.

You can see what the code looked like before the bug was added, and in many cases, just change it back to how it used to be?

The most obvious use case for history is "roll back this entire CL, it's broken".

Chesterton's Fence.