3 ms·
> What does that user need to hear? Not which file or subsystem was changed. But the reason there is a change in the first place. Doesn't that belong in the co
by superbaconman 4y ago
> What does that user need to hear? Not which file or subsystem was changed. But the reason there is a change in the first place.
Doesn't that belong in the code itself? Do we really want the intention of a change to sit under multiple levels of blame?
- ivan_gammel 4y agoIt’s called traceability of requirements and is important part of post-release QA. At any given moment of time it must be possible to understand the reason for change down to a single line of code.
- zaroth 4y agoThat’s lovely and all, but can’t be a commit message, which is primarily about succinct human understanding and setting context. A commit can certainly have computer readable metadata I presume!
- masklinn 4y ago> That’s lovely and all, but can’t be a commit message Of course it can. > which is primarily about succinct human understanding and setting context. You do know there is essentially no limit to how long a commit message is right?
- masklinn 4y ago> Doesn't that belong in the code itself? Do we really want the intention of a change to sit under multiple levels of blame? Yes? How would you encode the reasons for a change and for the way the change was implemented in code, dozens of lines of comments and ending up with files which are 90% comments floating in the void long detached from any code they were relevant to (and which may not even exist anymore)?