> Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either. It won't ever be perfect, but that

> Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either. 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.