It won't ever be perfect, but that doesn't mean we shouldn't strive to get as close as possible.
> Source control is the wrong tool for this job, that's what comments and tickets are for.
I agree that code comments play an important part in explaining why something is the way it is. Code comments and commit messages play a different role there, but they overlap and it can be tough to balance. Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result.
I disagree that tickets are a better way to convey this information. Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different, so all relevant information from such references should be in the comments or commit messages.
Agreed. So a linear history doesn't seem of much use if your current code is well documented, so are all of those pushing for linear history just poor at documentation?
> Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different
This is why Fossil ties the ticket system along with the VCS all in one system. In the end, I think the ticket system is almost as valuable as the source code, and shouldn't be causally tossed out.
Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.
> In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.
Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools.
I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job.
[1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.