Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Isn’t the intent described in the commit message, which is one of many ways the developer can use to share intent? Code is only the what and the how. The why should be in Wiki, Readmes, Commit, Issue tracker…


Let's say the change is to rename a variable. The patch format can never capture that the intent was to rename a variable. You can say so in a commit message, sure, but the action is never recorded, only it's effects, causing merges involving the rename to have conflicts


That’s because the code is data for an execution machine. All the other stuff are for the hunan mind. There’s multiple way to transition from one state of code to another, so mostly people record the existence of a transition (version control) and why it has happened (commits and other texts).

Recording how is not fruitful, unless the technique is good. In this case, the essence will be extracted, and it will become a checklist or a script.

If you have two itents producing conflicting patches, the merge intent that emerges is good because it brings empathy (understanding the message) and harmony (working code). And that’s why almost everyone says that the code itself doesn’t matter. Only the feature that it brings into play and the the mind that birth it do. It is a medium.

And a merge conflict is nice because it detects overlapping work and the fact that the concerned people should propably meet.


Typically intent needs to be well defined, such as PR discussions, use case / need assessments, or user stories on a backlog.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: