alt Hacker NewsBecause 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.
Replies
sevenzero • yesterday at 12:46 PM
Guess I must be doing something wrong to never have encountered this issue in my 5 years.
➕ show 7 replies
> A git commit [ideally] gives you the reason for the change
FTFY ;) I broadly agree, but it's important to note that, in practice, Git commits are hit and miss: they might save you a lot of time if they are well-structured and described properly, but they might also completely fail to give you anything of value (for the problem you're facing at the moment). Turning Git history into a broadly useful artifact requires a lot of discipline from everyone working on a codebase over its lifetime.
It's never totally useless, but it's often less helpful than it could be.
Recently, I turned to JJ for this exact reason: crafting a meaningful change history is much easier there, especially if you need to retrofit it after you're done with the implementation. jj's split, squash, and describe are a joy to work with, also because the interactive version lets you easily split or squash hunks (selected changes in the same file).